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
Calling GetIndirectShadowTree and holding on to the result - or holding
on to pointers from the LayerTreeState - is fine on the compositor
thread, but if we want to allow APZ to accept layer updates and scroll
offset sampling on some other thread, then we should avoid doing this.
This patch replaces calls to GetIndirectShadowTree with the
CallWithIndirectShadowTree function and ensures anything that outlives
the function is held on to with a RefPtr. Of course, this only takes
care of the more superficial concerns - we will also need to robustify
those classes' implementations to handle being called from multiple
threads; that will be tackled later.
MozReview-Commit-ID: E40JGFjooPo
--HG--
extra : rebase_source : e2f88c621433bb99919abf2d3a78ce1c53463d2d
This encapsulates the APZTestData better inside APZCTreeManager, which
we will want once we allow the hit-test tree update to happen on a
thread other than the compositor thread.
MozReview-Commit-ID: 66uSsagVfEu
--HG--
extra : rebase_source : 8e6ae809bfa0dde4e0e5fb2e321dd315174eafd6
Instead of keeping track of all the layers ids that we've seen during
the tree walk, we can now just get notified when a layer subtree is
removed, and clear out the state for that layers id at that point.
MozReview-Commit-ID: DVlWX3upWJ6
--HG--
extra : rebase_source : 8510418115a86a3c898f055db2cfa92cda2a0642
These two structs store very similar state (including duplicating the mask layer common clip count), and the former uses an expensive hashtable for lookups.
This patch combines the two, and uses a vector of entries instead of the hashtable so we can do the cleanup pass.
* * *
[mq]: fix
MozReview-Commit-ID: KamhbGAIqpD
--HG--
extra : rebase_source : 2d4c1522b04018dfab5cd4eabde828349548548c
image.animated.decode-on-demand.threshold-kb is the maximum size in kB
that the aggregate frames of an animation can use before it starts to
discard already displayed frames, and redecode them as necessary. The
lower it is set to, the less overall memory we will consume at the
expense of execution time for as long as the tab with the animation(s)
above the threshold are kept open.
image.animated.decode-on-demand.batch-size is the minimum number of
frames we want to have buffered ahead of an animation's currently
displayed frame. The decoding will request this number of frames at a
time to maximize use of memory caching. Note that this is related to the
above preference as well; increasing the batch size will in effect raise
what the minimum threshold. This simplifies the logic in patches later
in the series.
Now that what we use to decide whether a document is styled by Servo are only
prefs and the doc principal, we don't need to inherit the style backend type,
since unless the pref has changed, the result will be the same.
MozReview-Commit-ID: KBmeBn1cRne
In some cases we can end up with a PaintedLayerComposite still present
in the layer tree but with its mBuffer cleaned up. Whether this should
be occurring or not is still under discussion, but nevertheless a
PaintedLayerComposite without its mBuffer should not be considered
opaque, and treating it as opaque results in a black flash on OSX when
following links from the activity stream.
MozReview-Commit-ID: KklHEivfBWZ
--HG--
extra : rebase_source : aaad21550d520501b788505389ad7006dc41377c
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
