The APZUpdater class holds the methods that are to be run on the updater
thread. Note that there are a few differences between the APZSampler and
APZUpdater classes - most notably, APZSampler no longer has a
"RunOnSamplerThread" function because there should never be any need to
dispatch runnables to the sampler thread. There is still a
RunOnUpdaterThread in APZUpdater, as well as a mechanism for dispatching
runnables to the controller thread via the updater thread.
MozReview-Commit-ID: LLVWzRyhYWl
--HG--
extra : rebase_source : d3d2ae18b40f24473cab5567a48b67b8f478a733
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
Functions in APZSampler that are only invoked without WR (e.g. from
AsyncCompositionManager only) can be asserted as running on the sampler
thread. Functions that are invoked with WR need to be bounced onto the
sampler thread. In all cases the functions are called from the
compositor thread, and so we assert that as well.
MozReview-Commit-ID: JPgGlgUUsgg
--HG--
extra : rebase_source : 8b950d3386e1e64e766b76edaa7894b251fb8664
The methods on PAPZCTreeManagerParent are always invoked on the
compositor thread, which currently is always the same as the sampler
thread. When it does RunOnControllerThread calls, there is an implicit
ordering with respect to the sampler thread, because the controller
thread messages are always dispatched *from* the sampler thread.
When we move the sampler thread to be the render backend thread, we have
to preseve this implicit ordering, but we have to make it more explicit.
For example, if a content process sends a layers update followed by
a SetTargetAPZC message, it expects that the APZ will process them in
that order, as the SetTargetAPZC might refer to a scrollframe that was
just layerized. Currently, both these messages arrive on the compositor
thread; the layers update is processed directly as the compositor thread
is the sampler thread, and then the SetTargetAPZC message is bounced to
the controller thread. However, if the compositor thread is not the
sampler thread, then we would bounce the layers update to the sampler
thread, and bounce the SetTargetAPZC to the controller thread,
introducing a race. If SetTargetAPZC runs first bad things happen. The
solution in this patch is to bounce the SetTargetAPZC to the sampler
thread as well, so that it gets bounced to the controller thread only
after we have processed the layers update.
This patch accomplishes that by introducing a method on APZSampler that
does this "double bounce".
MozReview-Commit-ID: KI9wQQ9PZT4
--HG--
extra : rebase_source : 79d0d36a649f11cc795148cc86539a526c8beeae
This is functionally a no-op (it just moves the thread-bouncing code
from inside APZCTreeManager::SetLongTapEnabled to the call site in
APZCTreeManagerParent. The other call site, in
widget/android/nsWindow.cpp, is already known to be running on the
controller thread (which would be the Java UI thread in that case).
This makes the code in APZCTreeManagerParent more consistent and
simplifies the next changes.
MozReview-Commit-ID: 8VfEDVVFNl8
--HG--
extra : rebase_source : 02225ed5b80129a1d18b429eff93866a33d4ea86
Note that this also makes the utility functions instance methods,
because each APZSampler might have a different sampler thread instance.
MozReview-Commit-ID: 9dY8ZzVX6lR
--HG--
extra : rebase_source : 4dd58400aee5d9f2063abe0a912488b28ff74f9f
Due to an oversight in bug 1423370, the code I added was setting the
transform on a WebRenderLayerScrollData after initializing it, but the
initialization might have populated the transform. Thus the
transform-set that I added would have clobbered the transform. This
updates the code to combine the two transforms instead which avoids
the clobber.
MozReview-Commit-ID: 4mKJTLSMD9J
--HG--
extra : rebase_source : c486c5866739ab040d81f9f9a43b2b8a04c2d383
Instead of creating a new layer scroll data for every single
nsDisplayTransform item, we only create a new layer scroll data for
nsDisplayTransform items with perspective. In addition, we save the
transform from the non-perspective nsDisplayTransform items on the
StackingContextHelper, and then apply it to layer scroll data items that
are created by display items nested inside those nsDisplayTransforms.
This effectively makes two changes to the structure of the layer scroll
data sent to APZ:
(1) we will drop layer scroll data items for transforms that APZ doesn't
care about (i.e. the non-perspective ones that don't wrap APZ-relevant
display items).
(2) we will collapse layer scroll data items that only had a transform
into its descendant layer scroll data items. This should be functionally
equivalent, since the transform is still in the right place relative to
everything else.
The net result is fewer layer scroll data items.
MozReview-Commit-ID: HV6QPfuUrje
--HG--
extra : rebase_source : ecfe1810f9889e7ce5096e1bc42cc30a92b43b4a
Instead of hard-cording the root scroll frame id, get the value from
WebRender. This was previously hard-coded to 0, so when WebRender
switched to using 1 for the root scroll frame id, the positioning of
sticky frames were broken in subtle ways. This happened because they
were being parented to a root reference frame (which now uses the 0 id)
instead of the root scroll frame.
MozReview-Commit-ID: 66ArgKHGpWE
--HG--
extra : rebase_source : ff6937bf7fc8d4472eb074d0466c8dcd6fba54a8
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
FrameProperties have Remove() and Delete() methods. If you call
Remove() you now own the result, therefore we should delete it.
MozReview-Commit-ID: FybBYcbIZIH
--HG--
extra : rebase_source : fe1dc29d5a9bf5bac7b35452d3ad49b8aa0beb6a
Previously CreateWebrenderCommands would use GetLayerState to determine whether to use Webrender or
take the fallback path. GetLayerState would then under some cases call CanOptimizeToImageLayer()
which would get the image container using the appropriate flags for sync decoding.
Now nsDisplayBackgroundImage only uses CanCreateWebrenderCommands, which doesn't pass the correct
flags to image container, leading to reftest failures in some cases. This commit fixes that.
MozReview-Commit-ID: KlslXVHlRi5
--HG--
extra : rebase_source : aacb5fcae966cb9af8d8607e6c10e4c0822ea88d
Currently, we use a simple merging algorithm, because the more
complicated ones didn't work.
This code won't actually be used until we do blob image invalidation
in a follow up.
MozReview-Commit-ID: Q2Em3QC195
It looks like we can get layer tree adopted messages when the compositor
doesn't have an entry for that layer tree in sIndirectLayerTrees. So we
need to null-check all the things we pull out of that structure - all
the properties are already null-checked except for the mParent. This
patch adds a null check around that as well.
MozReview-Commit-ID: 2fb4SdvgSrG
--HG--
extra : rebase_source : d6d053e1ae11288f4bfc5459993564ed6ba22133
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
