So that we don't need to include nsStyleStruct.h in gfx any more.
MozReview-Commit-ID: 6nOaAbssLCz
--HG--
extra : rebase_source : 9c195c90277a4584dc14a6949e9eea53bcd8487c
gcc for arm/aarch64 target doesn't allow -msse2 command line option and it
causes option error, not warning. So it should not add this option for
non-Intel platform.
MozReview-Commit-ID: 9E6SGBMkT94
--HG--
extra : rebase_source : 3bd8d2f11d108c7463134c34f679244e6f4f3531
These were mostly exported because APZCTreeManager included them and now
they don't need to be exported any more.
MozReview-Commit-ID: 8W3vKOvzYW3
--HG--
extra : rebase_source : 8da95a203692ab3a88d37e66071b914682b44f14
This also includes unified build fixes that were needed as a result of
the shuffling around.
MozReview-Commit-ID: 1AGG3DHnN1m
--HG--
extra : rebase_source : 7399cea6dff2bd91ab305dee22d93b32382cc0be
Callers should be using one of the more specific subinterfaces like
IAPZCTreeManager (for controller-API methods) or APZSampler (for
sampler-API methods). There's also a bunch of android-specific
dynamic toolbar code that uses this function - I don't want to
deal with that right now, so instead of removing it entirely we can just
make it Android-only.
MozReview-Commit-ID: I8DYWLYoFgP
--HG--
extra : rebase_source : 75e05825194f9c6843506bb5d82e1a0c6e2b08bb
Although CrossProcessCompositorBridgeParent still needs to create a
dummy APZCTreeManager of its own in place, we can at least stop it from
grabbing the "real" APZCTreeManager from CompositorBridgeParent, which
allows access to methods that might not be properly guarded with respect
to thread safety.
MozReview-Commit-ID: Btvez3OkFPs
--HG--
extra : rebase_source : a4bec1769ff2fb899bb2e65f99f8e715f9a94c44
This fixes PrintTargetWindows::BeginPrinting to detect when the
user cancels and have it return NS_ERROR_ABORT in that case.
The rest of the changes are simply making sure that the various
call points up the call stack don't print a warning message if
NS_ERROR_ABORT is returned up from
PrintTargetWindows::BeginPrinting.
MozReview-Commit-ID: 6xZ5SPje6TT
This works around a rendering failure on Windows where the browser window opens
and remains white. Details of why this happens can be found in bug 1442748; this
workaround just forces a scene build if we get a GenerateFrame request after
having the root pipeline id set on the pending scene, but if it hasn't yet
been propagated to the current scene. This ensures the render isn't skipped
and prevents the C++-side frame throttler from preventing future composites.
This interface should be used for accessing any sampler-thread functions
on APZCTreeManager. Eventually the interface will handle thread
delegation so that if it is called from a thread that is not the sampler
thread it will redirect the calls appropriately. For now it just allows
to logically group the public APZCTreeManager methods that are to be run
on the sampler thread.
MozReview-Commit-ID: GArPvjfuYYr
--HG--
extra : rebase_source : 884cf6c3ce00f3df8ffe7dfa5fc12ef971f3cefc
This static function has only two call sites. One (in GPUProcessManager)
is unused, so it can be removed. The other (in
InProcessCompositorSession) takes the returned APZCTreeManager and
exposes it as an IAPZCTreeManager. Instead of doing this, we can simply
expose it as an IAPZCTreeManager from CompositorBridgeParent itself, to
reduce the number of places that can potentially grab a handle to the
APZCTreeManager.
MozReview-Commit-ID: BjLf6GSsnKz
--HG--
extra : rebase_source : ab24190a12053db06192fab4d1b7a932fe2d1724
The sampler thread is similar to the controller thread in that it doesn't
correspond to a particular actual thread, but instead introduces an
abstraction that allows us to reason about code flow and data ownership
that is logically grouped on a single thread. For now the sampler thread
remains mapped to the compositor thread, but eventually we will allow
it to be render backend thread when webrender is enabled.
MozReview-Commit-ID: D6i2t5lDvkv
--HG--
extra : rebase_source : 06211ad878973c76ca3fd618386bbbd0cfdd4821