In some cases we get a gecko display list that looks like this:
WrapList with asr(<A>, <B>)
Item with asr (<B>) and clipchain(<something> [A])
In this case, we would initialize the WebRenderLayerScrollData for the
nested item using a stop-at ancestor of A (because that was the leafmost
ASR from the containing WrapList) but the item itself has an ASR of B,
which is an ancestor of A. So when walking up from B we'd never hit the
stop-at ancestor, and so we'd end up duplicating metrics from the
containing WRLSD onto the nested WRLSD. This generated an assertion
failure in the APZ code.
This patch detects this scenario and skips adding metrics on the nested
WRLSD. This produces an APZ tree equivalent to what the non-WebRender
path would produce.
MozReview-Commit-ID: 8eo6pzXXKBd
--HG--
extra : rebase_source : 0581c54c4d9fa6ca08249e42b306c7155022bec7
The majority of this patch is just plumbing. The interesting parts are
in WebRenderLayerManager and APZUpdater/WebRenderScrollData. Unlike
ClientLayerManager, which updates the FrameMetrics on the client side
and sends the modified version over to the compositor, this WR version
just sends the update info over to the compositor, which then applies
the update to the metrics saved in APZUpdater before triggering the
hit-testing tree rebuild.
MozReview-Commit-ID: 4latUMa8RFw
--HG--
extra : rebase_source : d0aeaf5a9c8107bbcaf8b0da6d68a0f47f455be5
When passing the transforms from nsDisplayTransform items down to the
descendant display items, we need to make sure they are combined properly
so that the "ancestor transform" on the APZ side is correctly computed.
MozReview-Commit-ID: Di1FBLYGef5
--HG--
extra : rebase_source : 736e7cd375681f84ca2db8e6b98bf1a7525431d4
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : 85ee310ceaaff5fa8a1ccb513ffaf90904ace19d
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : 4554f908f42f761ddb2fca9be6bbe688c194c756
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : d39908b2be2565d22079b3e5e8df56316159a918
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
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
This just adds the boilerplate that goes with the new protocol, without
adding any of the actual messages. The protocol is managed by PGPU, and
there will be one instance per compositor. The parent side lives on the
main thread of the GPU process, and the child side lives on the main
thread of the UI process. The protocol is only instantiated if the GPU
process is active.
MozReview-Commit-ID: J4VzwmEfYTa
--HG--
extra : rebase_source : 397ddda8b0e76e5ed5f63783b1220ed7b4414d99
Most of this patch is just mechanical changes, but note that this patch
now makes the mFlags in scrollbar-container nsDisplayOwnLayer instances
have one of the direction bits set. As a result, this requires changing
the implementation of nsDisplayOwnLayer::IsScrollThumbLayer().
MozReview-Commit-ID: 2BLdbpz5Sa8
--HG--
extra : rebase_source : 27e7d90ce60c7f702fe77d8a3a0f7e3ae3e4a4ff
This also moves the function from nsLayoutUtils to be a function on the
ASR itself, which seems more appropriate.
MozReview-Commit-ID: 88lUmYi80P0
--HG--
extra : rebase_source : 3f7e4f875c3267f9f4c5c67e720912ceedb25719
These days (at least with webrender enabled), the layers id is created
by mashing together two uint32 values into the uint64. Printing it as in
base 10 produces some large number near the 32-bit boundary, and it's
much more legible/easier to compare when printed in hex.
MozReview-Commit-ID: JsGhqyLtDBv
--HG--
extra : rebase_source : ed60d26d8223d968f37e8d933e60b1ee6552d1e9
This code has been unused since the removal of layers-full WR codepaths.
MozReview-Commit-ID: JQn55Kbz5rr
--HG--
extra : rebase_source : af6995265c02a1ddfccbc37adb633bc2b240ec8b
This code has been unused since the removal of layers-full WR codepaths.
MozReview-Commit-ID: EAhRrZXLKKr
--HG--
extra : rebase_source : c33f915461c724c61b11804a9cecb960728fd6df
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
The three main changes in this patch are:
(1) Move the code to emplace_back a new WebRenderLayerScrollData to
after the display list recursion. This is necessary so that when we
empty the temporary mLayerScrollData stack into the final mScrollData
structure things end up in the right order.
(2) Maintain a stack of ASRs as we recurse so that when we are building
a given WebRenderLayerScrollData, we don't add scroll metadatas that
are already present on its ancestors.
(3) Compute the number of descendants created for each layer scroll
data item and record it, so that we can properly reconstruct the
shape of the tree.
MozReview-Commit-ID: BSdX78AqBNZ
--HG--
extra : rebase_source : 0bb4133572d74fb756476e1c5954b17f114fe7d0
Instead of the WebRenderLayerScrollData code knowing about all the
different display item types, it makes more sense to move this logic
into the display items.
In addition to avoiding dis-encapsulating the data from nsDisplayItem subclasses,
this makes it easier to handle two specific scenarios:
(1) the case where an nsDisplayItem A subclasses another nsDisplayItem B, but A
and B have different types returned by GetType(). Previously A and B would have
to be handled explicitly in the WebRenderLayerScrollData switch statements,
which doesn't scale well if new types are added. With the new approach the
virtual function is shared down from A to B and so takes care of it. This is
particularly relevant for types like nsDisplayOwnLayer which have a number of
subclasses.
(2) the case where a display item *might* have APZ-relevant information.
In this case the type of the item alone is not sufficient to determine
if we need to create a new WebRenderLayerScrollData for it. Instead, we
need to access specific state inside the display item. This is now
handled by the UpdateScrollData function returning true when passed
nullptr arguments, and replaces the switch statement in
WebRenderLayerManager that updated forceNewLayerData.
MozReview-Commit-ID: FlfHlgSccSn
--HG--
extra : rebase_source : d1fe841724cc6020433aea31ffb5214d8a44d0a9
This adds handling for nsDisplayRemote frames, so that we create a
WebRenderLayerScrollData item for each nsDisplayRemote frame that we
encounter. This is the equivalent of a "ref layer" in a normal layer
tree, and allows the APZ side to glue together the scroll data from
different processes into a full tree.
MozReview-Commit-ID: 3lgsqtCKQya
--HG--
extra : rebase_source : eb93be1ef415349e00c09d7274d49fcf7992d197
The semantics of the WebRenderScrollData structure is that the per-layer
structures form a tree with a single root node. When we build the data
structure from the display list, we are generating (for now) a flat
list. Therefore we need to synthesize a root node in order to make stuff
work as intended.
MozReview-Commit-ID: IDXyziBO7pk
--HG--
extra : rebase_source : 99486a4c5b5e9938c4b7bbaa3f710d25e73d4401
Until now WebRenderScrollData was only used with "layers" WR
transactions, but we want to use it with layers-free transactions as
well. As such, we need to allow collecting information from display items
instead of layers. This restructures the code a little bit to allow
that. This patch should not have any functional effect on the "layers"
codepath, but on the "layers-free" codepath it is now actually
populating some rudimentary data into the WebRenderScrollData before
sending it across. This will be fleshed out in future patches.
MozReview-Commit-ID: BROqpsHPRND
--HG--
extra : rebase_source : 8510c52895e6be5cb546b42b02d56ec067de0623
This also updates the WebRenderScrollDataWrapper function as it is meant
to be semantically equivalent to the LayerMetricsWrapper one, which
allows removal of a flag propagation.
MozReview-Commit-ID: 9DBx4qbhq5A
--HG--
extra : rebase_source : 3201d8a4bb7192ecdbe95983b605ac53b1a28c50
This mostly just copies the functional parts of the APZTestData code from
ClientLayerManager into WebRenderLayerManager, and propagates the paint sequence
number over to the compositor using the existing WebRenderScrollData machinery.
MozReview-Commit-ID: LHupFpqtWTX
The propagation happens via LayerMetricsWrapper or WebRenderScrollDataWrapper.
MozReview-Commit-ID: GBZUnNn3zjN
--HG--
extra : rebase_source : 4c63269480154a95d5faedf1b4972f7d3373cb5a
This propagates the animation id for a scroll thumb's stacking context over to
the APZ code, and stores it in the HitTestingTreeNode.
MozReview-Commit-ID: 5O13Xko2Bph
This is preparation for future changes that will add fields to ScrollThumbData
that will be accessed via HitTestingTreeNode.
To accomplish this, this patch also exposes the entire ScrollThumbData via
LayerMetricsWrapper and WebRenderScrollDataWrapper.
MozReview-Commit-ID: 1Ed8Z80Wk1V
--HG--
extra : rebase_source : 86cce84eab0cd8bcd2998f1682137e9514bb1fb5
Also remove a vestigial declaration of the previously removed method
HitTestingTreeNode::GetScrollThumbLength().
MozReview-Commit-ID: 3BvFNeGwPXd
--HG--
extra : rebase_source : 6cc6d2f2e3ecc4dedce2b83f6b0faf819f4be0f8
The patch also renames Layer::SetScrollbarData() to Layer::SetScrollThumbData()
for clarity.
MozReview-Commit-ID: DVwJ3DMl3Zs
--HG--
extra : rebase_source : 7b2bfccf1351c82bb16296635e69d5488c87a50f
This puts all the other things that APZ needs into the
WebRenderScrollData object. The main exception is the scroll clip - I'm
not totally sure how that will be handled yet, so for now we just return
no clip from WebRenderScrollDataWrapper.
MozReview-Commit-ID: 1IhGhSFiPYi
This mainly implements the GetLastChild and GetPreviousSibling functions
in the WebRenderScrollDataWrapper, and adds helper functions that are
needed to make that possible. This allows the WebRenderScrollDataWrapper
to simulate a full "LayerMetrics" tree using the information in the
underlying WebRenderScrollData object.
MozReview-Commit-ID: K82Ud2gAo8K
This adds a WebRenderScrollData class (which contains a list of
WebRenderLayerScrollData objects, among other things), and adds it to
the DPEnd/DPSyncEnd messages sent across PWebRenderBridge. These classes are
skeletons for now (more stuff will be added to them in future patches).
MozReview-Commit-ID: 9duxwlUpdu7
