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.
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
--HG--
extra : rebase_source : 77c34ec1cbbc1c0fe4d1971feb131d30c97f0d66
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: AgMyNapY2Og
--HG--
extra : rebase_source : d8522d8e806522a4a0e8b2cd1669db0374bd5e63
For various reasons, we want to be pushing the layer's local clip rect
outside of the stacking context rather than inside it. Not only is this
more correct with respect to the semantics of the layer tree, we also
need it in order to properly handle fixed-positioning of layers with
async scrolling.
This patch does the bulk of the work to make this happen. Most of the code
in the individual layer classes to process the layer's local clip rect
is removed, and instead a function in ScrollingLayersHelper is added to
deal with it. There are a couple of places that individual layer classes
still handle this but those will be removed in future patches. Note that
the individual layer classes still need to provide a clip rect of some
sort in order to push their display items, and now they simply use their
visible region bounds for this purpose.
MozReview-Commit-ID: IBmfUdJwYx1
--HG--
extra : rebase_source : 3f48a707f35a398711813d859af1e7184f19fd40
This adds an RAII helper and uses it in RenderLayer functions. When APZ
is enabled, the RAII helper pushes a scrolling clip for each scrollable
metrics on the layer. It also pops off the scrolling clips on
destruction. Note that this should happen before any other things are
pushed into the WR display list for the rendering of a layer, since
those things should be subjected to the enclosing scrolling clips.
If APZ is disabled, this skips pushing the scrolling clips.
MozReview-Commit-ID: 1qv9egKbbok
The only remaining callers of RelativeToParent() are in
StackingContextHelper itself, which we can remove now by having the SCH
take a parent SCH and use it instead of RelativeToParent(). This patch
implements this change.
This makes a failing test pass, because of how preserve-3d container
layers work. Specifically, preserve-3d container layers render their
descendants in z-order, not in tree order. If those children were assuming
that their parent had already pushed a stacking context, that assumption
may have been false because the parent might have not yet been rendered
because of z-ordering. By using the StackingContextHelper chain instead
of the layer tree ancestry, we fix the stacking-context-relative coordinates
being used in the descendant subtree of preserve-3d container layers.
MozReview-Commit-ID: HzZvBuAlMdB
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
This class is a RAII class that can be used to push a stacking context
with properties from a WebRenderLayer. It can also then be used to
convert rects in the layer coordinate system to be relative to the
stacking context, which is what we want for passing to WR.
MozReview-Commit-ID: 1WVrfRYqLqc
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
This removes the call to push_scroll_layer in wr_push_stacking_context, so that
it's now possible to push a stacking context without necessarily pushing a
scroll layer. There is already a separate function to push a scroll layer so the
call sites can do that. This patch just changes all the call sites that were
pushing a stacking context to also push a scroll layer, so there should be no
functional change. Future patches can remove the spurious scroll layers.
MozReview-Commit-ID: FtCkc9JQd8l
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 basically just splits the enum in two and does the necessary plumbing. The
worst part is that now DisplayItemLayers need to have two arrays of commands.
Fortunately, this will be going away in the future.
This makes it so we don't send the child side commands to the parent.
Ryan Hunt
sotaro
Sebastian Hengst
Nicolas Silva
Kartikaya Gupta
Carsten "Tomcat" Book
David Anderson
Markus Stange
Alexis Beingessner
Ethan Lin
Mason Chang
Jeff Muizelaar
Matt Woodrow
Daniel Holbert