The main-thread codepath projects 3D transforms to 2D in
nsLayoutUtils::GetTransformToAncestor() when the transformed frame
returns false for Combines3DTransformWithAncestors().
This patch makes the transforms sent to APZ behave the same way.
Differential Revision: https://phabricator.services.mozilla.com/D142522
So, it turns out I didn't fully test the patch from bug 1740262 after I made my
final changes to it. A change that I had in the patch which I thought was
unnecessary, because it didn't fix the problem by itself, turns out to in fact
be necessary. It turns out we still need to inherit the parent stacking
context's `mRasterizeLocally` value inside gecko, or else we could have scale
changes which get dropped on the WebRender side. I do think long term WebRender
should handle all of this itself, because I believe there are still potential
issues lurking here when we start to think of this across the process boundary,
but I don't think I'm the right person right now to untangle everything to
cleanly move everything necessary into WebRender, so I think the solution for
right now is to have Gecko somewhat but not entirely reduntantly handle raster
space inheritance itself, in addition to WebRender handling raster space
inheritance in order to partially cover the process boundary case. This is not
a pretty solution, but as far as I can tell it fixes the issues that bug
1730710 introduced without regressing the performance back to pre-1730710
levels.
Differential Revision: https://phabricator.services.mozilla.com/D132308
This actually does two things. One: it lets child stacking contexts inherit out
of process raster spaces by checking the parent stacking context's raster space
inside WR itself, and Two: it mirrors the logic in get_raster_space_for_prim
which undoes the device_pixel_scale for pinch zooms in order to get a
consistent glyph rasterization scale. This second thing won't affect the test
page linked in the bug, but it will affect the performance of, say, animating a
whole browser's scale, which is useful for reasons.
Differential Revision: https://phabricator.services.mozilla.com/D125562
Maybe<T*> is a redundant representation if there is no semantic
difference between Nothing() and Some(nullptr), and just makes
for cumbersome access syntax.
Differential Revision: https://phabricator.services.mozilla.com/D120568
Whenever the asr of the deferred transform item differs from the current asr and we are about to enter a new StackingContextHelper (as opposed to just when we enter a transformed frame) flush the deferred transform item, so it's transform doesn't get lost.
This is similar to https://phabricator.services.mozilla.com/D8111. In fact we are extending https://phabricator.services.mozilla.com/D8111 to every time we enter a StackingContextHelper. https://phabricator.services.mozilla.com/D8111 was concerned with solving the case of having two nested transform items with different asrs and making sure we don't lose the outer transform item, here we need to solve the case of an outer transformed item and an inner StackingContextHelper (which is not for a transform) with a different asr and making sure we don't lose the outer transform item.
Note that some of the items I added CreatesStackingContextHelper return true don't always make a new StackingContextHelper. It seemed better to be consistent and I think the only downside is a little less perf because we have to create a few more scrolldata nodes.
Differential Revision: https://phabricator.services.mozilla.com/D118815
Currently when selecting the scroll root for picture caching, if a
non-Zoom transform is encountered we give up and select the root
spatial node. This is because the transform may be non-axis aligned.
When the Fenix dynamic toolbar is enabled, fixed position items must
create a spatial node with an animated transform, so that they can be
positioned asynchronously by APZ when the toolbar moves.
The combination of these two things means for that scroll frames
within fixed position items we always select the root spatial node,
meaning that the entire contents invalidates continuously while
scrolling.
To fix this, add a flag to the Transform ReferenceFrameKind which
marks the transform as always being a 2D scale or translation. When
selecting the scroll root, we can continue searching through such
reference frames, as we already do for Zoom frames. Set this flag true
for references frames created due to the dynamic toolbar.
Additionally, assert that the transform is indeed a 2d scale or
translation after it is resolved.
The condition of the transform being only a 2d scale and translation
is shared with ReferenceFrameKind::Zoom, so that has been removed and
its uses updated to use this new flag instead. An additional
should_snap flag has also been added, so that we continue to snap zoom
transforms, and additionally snap the dynamic-toolbar related
transforms too.
Lastly, this adds some unit tests for find_scroll_root.
Differential Revision: https://phabricator.services.mozilla.com/D106809
When combining transform matrices for deferred transforms, we were multiplying
them in the wrong order. This caused incorrect behaviour when one of the matrices
had a scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D96199
In StackingContextHelper::StackingContextHelper we want to handle the case of "no passed in transform" differently from "passed in transform but it cannot be drawn 2d". This is a little tricky because ChooseScale always has a transform passed in: in the non-wr case it is a scaling matrix by the parent scale. We could call ChooseScale if canDraw2D is false and get the same value for mScale but we also need to keep mInheritedTransform in sync.
This issue arose before: https://bugzilla.mozilla.org/show_bug.cgi?id=1449958#c3
And we want to be careful not to regress that bug, that bug was concerning content without a transform, so we should be good.
The testcase has a parent element with rotateY(-80deg) and a child element with rotateY(80deg), the combined transform is flat with no scaling even though each transform individually would have a very small x scale. There's no way to choose a good scale by looking at each transform individually, and since we only currently store transforms as 2d matrices we can't look at the full combined transform in order to choose a scale. Thus we must use a unit scale, like ChooseScale does.
Differential Revision: https://phabricator.services.mozilla.com/D75289
Back when webrender did not call FrameLayerBuilder::ChooseScale (it was called ChooseScaleAndSetTransform back then until it was factored out in bug 1415987) bug 1449640 landed which made the webrender scale choosing more closely align with FrameLayerBuilder::ChooseScale by not computing a scale of there was preserve3d or perspective involved. That patch had a bug, it looked at the parent stacking context helper to see if it had preserve 3d, but FrameLayerBuilder::ChooseScale looks at the current "stacking context".
This didn't cause a problem in the testcase from this bug until bug 1569215 landed. In the testcase in this bug we have a stacking context with a 2d transform whose parent stacking context is preserve3d. So we pass down the scale from the parent stacking context and completely ignore the scale induced by the 2d transform. Passing 1.f to ChooseScale instead of the parent scale factor "undid" this mistake, so when that was fixed we regressed this testcase.
Differential Revision: https://phabricator.services.mozilla.com/D69167
This might seem like we are including the parent scale twice because it is also included in mInheritedTransform but FrameLayerBuilder::ChooseScale only incorporates the passed in scale when combining it with a scale computed purely based on the local transform induced by this stacking context item.
This also fixes bug 1564698 and doesn't regress bug 1495163 (the only testcase I can still find for the regressing bug, bug 1415987).
Differential Revision: https://phabricator.services.mozilla.com/D39867
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items before encountering the
APZ-relevant display item. In this case we need to somehow accumulate
all the deferred transforms. This patch accomplishes that, and includes
a mochitest that exercises the relevant behaviour.
Depends on D8109
Differential Revision: https://phabricator.services.mozilla.com/D8110
