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
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
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
If we set a transform in push_stacking_context, it changes the internal
WebRender behaviour to make that stacking context a reference frame, and
things inside it are positioned differently. This is true even if the
transform is an identity transform.
In most cases we are hitting this and sending an identity transform
through, when in fact we want to be sending a None value to WebRender so
that it doesn't create reference frames. This is a partial fix, a proper
fix will be done in bug 1345577 by separating the CSS transform from the
other transforms that FrameLayerBuilder invents.
MozReview-Commit-ID: ElSs3hFMD2D
In order to have the scrollbar thumbs reflect the async scroll position, we're
going to re-use the API for OMTA. That is, we set an animation id on the
stacking context for the scroll thumb, and we'll update the transform on the
stacking context at composite time based on the async scroll position. For this
to work we need to ensure that the scroll thumb does in fact have an
animation id set on it.
MozReview-Commit-ID: 6TvRemxRUrR
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 cleans up WebRenderRefLayer::RenderLayer to use typed coordinate
systems and the StackingContextHelper. Note that this patch contains a
functional change, because the clip rect pushed no longer includes the
transform on the ref layer itself. It's not clear to me why we were doing
that, and didn't seem correct.
MozReview-Commit-ID: K7FoeLnXc56
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
Need to pass the default transform/opacity to compositor if animations
exist because it is possible that gecko fails to get animated value
after animation sampling, like an animation with delay.
MozReview-Commit-ID: IK06hWvaSPf
Pass empty opacity(transform) in stacking context when there exists opacity(transform) animations and
the final opacity(transform) value will be resolved on the compositor after animation sampling
MozReview-Commit-ID: 6pF9Oe8Ks2I
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 is functionally equivalent since one variant of the
PushStackingContext was already delegating to the other (in
DisplayListBuilder).
MozReview-Commit-ID: 8PfMm3bHeSZ
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
Note that in upstream WR the push_scroll_layer API has already been
renamed to push_clip_node, so conceptually the same API covers both
"scrolling clips" (aka scroll layers) and non-scrolling clips. So using
the same underlying API for two different WebRenderAPI.h functions makes
sense.
MozReview-Commit-ID: He7jBVqZuLn
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
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.
