The MediaStreamGraph relies on having at least one message sent to its message
queue on creation, or it will just sit there and do nothing, and block shutdown
because its not running its rendering loop, so it's not progressing in the
MediaStreamGraph life cycle state machine.
This patch makes sure the `captureStream` will succeed before creating an MSG.
MozReview-Commit-ID: CN1arWydmxC
--HG--
extra : rebase_source : b59a8ec4de17aa90d274819ea0c7d687673c8075
We should not let the ppm to do work before the first paint in a new cp. This patch
makes sure that we only let the ppm spawn a new process after the last process reached
an idle state AND the main process becomes idle too. r=mrbkap
The patch fixes a problem on windows. Before the patch, there was a case that moved tab was not re-rendered. When WebRenderBridgeParent reveived obsolted transaction, DidComposite() was not returned to a client side. It stopped nsRefreshDriver to trigger a next transaction.
When the tab move happens, related non-root WebRenderBridgeParent is updated as to render to different webrender instance. webrender does not support of sharing resources and keys yet. Then when the tab move happens, the patch just removes all keys and resources that belongs to previous webrender. Ideally all resources that belong to WebRenderBridgeParent should be reallocated in an update webrender. But the patch does not do it, instead it just request WebRenderBridgeChild to re-allocate all resources again for simplicity. Performance improvement will happen in a future patch.
This patch support only tab move that uses only raw data external images. Support of native texture external images will happen in a future patch.
Stable Rust currently has logic similar to the following for finding the
linker on Windows:
if VCINSTALLDIR in os.env:
search for things in PATH
if found, return, otherwise fallthrough
look for MSVC installations of various kinds
For our current MozillaBuild setup where we clear out PATH prior to
invoking Cargo, this works: even though VCINSTALLDIR is set and we
(unsuccessfully) search through an empty PATH, we'll still fallback to
looking for MSVC installations.
Beta Rust has altered this search strategy:
if VCINSTALLDIR in os.env:
search for things in PATH
return the result of the search, regardless of success
look for MSVC installations of various kinds
Note that in the above logic, if VCINSTALLDIR is set, we are only going
to try looking in PATH for an appropriate linker. Since PATH is empty
in our current MozillaBuild setup, beta Rust will therefore fail to find
the correct linker. This failure causes numerous problems.
Since Firefox is already trying to "clean" the environment that Cargo is
invoked in, we should work a little bit harder by unsetting VCINSTALLDIR
entirely, and simply force Rust to search for known MSVC installations.
Making this change makes stable and beta Rust behave identically.
(We don't have to worry about this distinction in automation, because
the "cleaning" code is only activated when we detect a MozillaBuild
shell.)
llvm-config on Windows can return a path for the clang binary which does
not end in ".exe", which then causes failures when attempting to check
for the existence of the file. Rather than attempting to simply tack
".exe" onto the file if it's not already there, delegate to
moz.configure's `find_program` function, which will take care of that
case and several others besides.
Paul Adenot
Beekill95
Kris Maglione
Ryan VanderMeulen
Sebastian Hengst
Gabor Krizsanits
Geoff Brown
sotaro
Ehsan Akhgari
Nathan Froyd
ffxbld
johndai1984
Carsten "Tomcat" Book
Michael Brennan
Mats Palmgren
Nicolas B. Pierron
Petr Sumbera
David Anderson
Alexander Surkov
Ben Kelly
Jan de Mooij
Yoshi Huang
Andrea Marchesini
Gijs Kruitbosch
Dão Gottwald
Aaron Klotz