Originally we use the nsDisplayItem::ToReferenceFrame() to get the offset. But the
function doesn't consider some style effects. We should take the top-left corner
of the display item bounds as the offset.
MozReview-Commit-ID: LiPcA0vjoD7
--HG--
extra : rebase_source : 2711ca3d1b05c3f0aae6943f959b9ab41b273200
This patch ensures that we push clips in WR for each display item,
reflecting the display item's clip chain as computed in Gecko. A display
item will often share part or most of its clip chain with other display
items, so we try to reuse the corresponding WR clip ids as much as we
can instead of defining new duplicated clips.
MozReview-Commit-ID: LkBh8LIpQ4J
--HG--
extra : rebase_source : 5af1de0931f1d059e98b5c66b15988961503e114
mLastCanvasDatas store used WebRenderCanvasData in last full
transaction. So that in next empty transaction, we can update canvas
content through mLastCanvasDatas.
MozReview-Commit-ID: 2H2m8R7Kzwf
This patch collapses the data from event regions display items that have
the same ASR. However, it only does so if there's no other display items
interleaved in between that forced their own scroll layer data.
MozReview-Commit-ID: IkQSISc2bwc
--HG--
extra : rebase_source : d3001675d516c303d5452aafc57c996192e11e98
We want to collapse all event regions display items with the same ASR
(and that are not interleaved with other APZ-relevant display items),
regardless of the recursion level in the display list. In order to
facilitate this we need to track the last ASR seen in the display list
regardless of the recursion level.
MozReview-Commit-ID: Lw5ZwwmqnkE
--HG--
extra : rebase_source : 14eba8a04a7cbeaa41313aed969484bf5b6f46ad
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
We should do SchedulePaint in nsImageFrame for layers-free mode and set
invalid flag to make sure the image will be repainted.
MozReview-Commit-ID: 2lXElZ151Qa
--HG--
extra : rebase_source : 56045f66f3b36afe8a6327b841d80073f1d038cb
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 patch allows us to decide whether to use blob images depending on a MustPaintOnContentSide flag exposed by each display item. If any of the display item assigned to a given painted layer data have this flag, then the painted layer data is marked as preferring content side painting and the webrender layer manager uses this information to decide whether to create a regular content layer or serialize the drawing commands with blob image. This is useful for items that must be painted on the content side such as scroll bars, checkboxes, buttons, etc. Using blob images for these makes us first paint the widget on the content side, then serialize the painted pixels and blit the content again in the blob image which has a lot more overhead than painting the content into a layer and sharing it with webrender directly.
Layers are retained between transaction and we store some data in the layers.
Thus, if we no longer use layers, we need find another storage to place
those data. I use frame's property to retain WebRenderUserData between
transaction.
MozReview-Commit-ID: Ku5VGBXa3w6
--HG--
extra : rebase_source : 636653f78d1d6c310726a1a2c944141dc691decc
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
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
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
In addition to updating gfx/webrender and gfx/webrender_traits, this patch:
- Updates the webrender_bindings Cargo.toml file for version bumps
- Updates the Cargo.lock files and revendors the third-party rust dependecies
- Updates the webrender bindings for a change in the display list construction
and finalization API in WR csets 425155a and 1eb84eb.
We now have to pass around a content size parameter to construct a display list,
and we get back a content size from finalizing the display list. Since we pass
the finalization results over IPC to WebRenderBridgeParent, we need to update
the IPDL as well to pass this around.
- Updates the webrender bindings for a change to scroll_node_with_id in WR cset
48a098f.
- Updates the webrender bindings for a change to push_text in WR cset 3287c15.
This is needed in part 3 to update WebRenderTextLayer::RenderLayer, so
that it no longer assumes the parent container layer has pushed a
stacking context, and instead explicitly uses the StackingContextHelper.
MozReview-Commit-ID: 9twUmDgUipX
First, hook the Layer's ClearAnimation API to delete unnecessary
animations in next layer transaction. Second, add another async
DeleteCompositorAnimations API to delete animations on the compositor,
especially calling this API before WebRenderLayerManager got destroyed.
MozReview-Commit-ID: 4mbj5IgsXYa
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
Animations in content side could be removed easily by changing CSS, but the
CompositorAnimationStorage in parent side doesn't get updated. Therefore,
we store the layer's CompositorAnimationsId before layer is destroyed in
WebRenderLayerManager and then send out these discarded ids to parent on
the next layer transaction.
MozReview-Commit-ID: D4kbYsgLl4P
If the GPU process resets, we get a call to destroy the WebRenderLayerManager.
This in turns tries to send messages over the PWebRenderBridge channel which
has already been torn down. We should detect this case and avoid sending the
messages.
MozReview-Commit-ID: AV3q0WVpPN5
--HG--
extra : rebase_source : 12d5b46a473e9505109ce2797a196a6e220d6d35
This is a largely uninteresting patch that just uses the DisplayListBuilder
directly. A wonderful cleanup patch will come after this. One of the more
interesting pieces is the use of PushBuiltDisplayList. This is needed for
handling empty transactions. See https://github.com/servo/webrender/pull/934
for more info.
This simplifies the logic around displaylist builders and
makes us push immediately instead of deferring it. The data
we used to pass to pop() is now passed to push().
This is also closer to what Servo does.
In a follow up I'll rename some of the methods to closer
align with the webrender names.
MozReview-Commit-ID: AfkwT7DzJ8o
add width, height and format arguments in AddExternalImageId/AddExternalImageIdForCompositable()
turn to use AddExternalImageId() for TOpDPPushExternalImageId op.
send the Image/ExternalImages removing messages just after DPEnd()
MozReview-Commit-ID: KkjzB6ibKas
This simplifies the logic around displaylist builders and
makes us push immediately instead of deferring it. The data
we used to pass to pop() is now passed to push().
This is also closer to what Servo does.
In a follow up I'll rename some of the methods to closer
align with the webrender names.
