Instead of just storing the gfx::Matrix from the nsDisplayTransform on
the stacking context for scrolldata use, we now store a pointer to the
entire nsDisplayTransform item. We will need this in the next patch.
This patch should not have any functional changes.
MozReview-Commit-ID: 7qsZpL3Ka0X
--HG--
extra : rebase_source : b42957c83ef0591e72fa5b58ceb6650fda96e0b2
Capture a snapping surface transform. This is used
by svg/blob code to compute an fractional offset
to the nearest intermediate surface.
MozReview-Commit-ID: 6EFNvluvzvA
--HG--
extra : rebase_source : f26e7fa823883e93742970c2e8d687319a7eaf5b
This is just plumbing, no functional changes yet.
MozReview-Commit-ID: FlmnMVammse
--HG--
extra : rebase_source : edede45a77a829dbd125dc1f18a4c2a4bc8087c1
When a transform thinks it's animated we should abandon screen rasterization
and instead favour local rasterization. This produces a more visually
pleasant rendering, as pixel-snapping "wobbles" the text between
frames.
The float scale of GlyphRasterSpace::Local is currently unused, but this
PR tries its best to set it to a reasonable value, based on discussion
with glennw about the intended semantics. We agreed it should specify
the scale *relative* to the parent stacking context, which means it's
just whatever scaling the stacking context's transform applies. It's
possible we'll need to clamp this value or make it properly 2-dimensional
later on.
Some book-keeping is added to StackingContextHelper to ensure that
GlyphRasterSpace::Screen is never requested by a descendent
of a stacking context using GlyphRasterSpace::Local.
nsDisplayMask is changed to use a StackingContextHelper to ensure
rasterSpace is properly propagated.
In addition, this is the first commit making use of cbindgen's new support
for bridging Rust enums natively into C++! This bumps our minimum cbindgen
to 6.0.0 (just released).
MozReview-Commit-ID: 9AlsB6nUheB
--HG--
extra : rebase_source : 247e5b197e998682cb4bb74f6f9319a9a4dd3264
When a transform thinks it's animated we should abandon screen rasterization
and instead favour local rasterization. This produces a more visually
pleasant rendering, as pixel-snapping "wobbles" the text between
frames.
The float scale of GlyphRasterSpace::Local is currently unused, but this
PR tries its best to set it to a reasonable value, based on discussion
with glennw about the intended semantics. We agreed it should specify
the scale *relative* to the parent stacking context, which means it's
just whatever scaling the stacking context's transform applies. It's
possible we'll need to clamp this value or make it properly 2-dimensional
later on.
Some book-keeping is added to StackingContextHelper to ensure that
GlyphRasterSpace::Screen is never requested by a descendent
of a stacking context using GlyphRasterSpace::Local.
nsDisplayMask is changed to use a StackingContextHelper to ensure
rasterSpace is properly propagated.
In addition, this is the first commit making use of cbindgen's new support
for bridging Rust enums natively into C++! This bumps our minimum cbindgen
to 6.0.0 (just released).
MozReview-Commit-ID: 9AlsB6nUheB
--HG--
extra : rebase_source : 978e51dbedeb1542e0829752b7f828ffeb2872e9
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
This matches the behaviour of ChooseScaleAndSetTransform()
MozReview-Commit-ID: LxtkQn2XdYT
--HG--
extra : rebase_source : 9d2a9b1af9bf039def408f86982da835b7120e36
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
Instead of creating a new layer scroll data for every single
nsDisplayTransform item, we only create a new layer scroll data for
nsDisplayTransform items with perspective. In addition, we save the
transform from the non-perspective nsDisplayTransform items on the
StackingContextHelper, and then apply it to layer scroll data items that
are created by display items nested inside those nsDisplayTransforms.
This effectively makes two changes to the structure of the layer scroll
data sent to APZ:
(1) we will drop layer scroll data items for transforms that APZ doesn't
care about (i.e. the non-perspective ones that don't wrap APZ-relevant
display items).
(2) we will collapse layer scroll data items that only had a transform
into its descendant layer scroll data items. This should be functionally
equivalent, since the transform is still in the right place relative to
everything else.
The net result is fewer layer scroll data items.
MozReview-Commit-ID: HV6QPfuUrje
--HG--
extra : rebase_source : ecfe1810f9889e7ce5096e1bc42cc30a92b43b4a
The only call to IsBackfaceVisible() was removed when we added proper backface
visible support.
MozReview-Commit-ID: ALAF4a0ScQJ
--HG--
extra : rebase_source : 9a138f9ca4244105b4692b340c95e1dbc03f0356
In bug 1426386, I made it so that in some cases, part or all of the
transform component of a stacking context got moved to the bounds
top-left. However I neglected to update the ScrollingLayersHelper, which
was relying on the transform to know if it could reuse clips across a
stacking context boundary. It now also needs to check the bounds
top-left as a result of the aforementioned change.
MozReview-Commit-ID: 7mDRSYqZ8bF
--HG--
extra : rebase_source : bdf433c772853d39e29c0288776db7a88129ac2f
When a clip is defined in WebRender, any transforms on the containing
stacking contexts are baked into the clip's position. Therefore, trying
to use a clip that was defined inside a transformed stacking context in
other parts of the WR display list doesn't work properly. This was a
latent bug in ScrollingLayersHelper that was previously not exposed
because in these cases Gecko itself creates separate
DisplayItemClipChain items. Now that we are going to deduplicate those
DisplayItemClipChain items, it exposes this latent bug which we need to
fix.
MozReview-Commit-ID: Icd7L1JuY8s
--HG--
extra : rebase_source : 08749125b68b537244a054d00a41f671670d00bb
Now that ToRelativeLayoutPoint does no math we should be able to
eliminate a copy of the glyph buffer.
MozReview-Commit-ID: 1o6awTyE95v
--HG--
extra : rebase_source : 0133fd64fb96c1d5541f036b7f7f3ec8701cd3fd
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
My original understanding of the API was flawed, and so while I had
position:sticky working in some cases it didn't work properly in a lot
of other cases. This patch corrects the usage of the API to match what
WR is expecting and fixes a lot of test cases.
MozReview-Commit-ID: AdMux19Fk9U
--HG--
extra : rebase_source : e7f970a710b2079501a91eeeac8c292b603210dc
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
This backs out bug 1399050, bug 1394308 (2 patches), and bug 1391499. I
believe these patches sent us down a path that would make the code
increasingly more complex, when in fact we can do a more "direct"
translation from the gecko display list to the WR display list and make
things a lot simpler and more correct.
MozReview-Commit-ID: ZXXkI9DXiY
--HG--
extra : rebase_source : 47ce1fcb87f0c21d158ee06f38e2b3303f999270
Expose the API to get/set inherited scale from stacking context and we can
use these APIs to calculate correct scale for OMTA
MozReview-Commit-ID: DZEkodHTy8v
--HG--
extra : rebase_source : be3c978c8f48c9b1bfcd01cff6bb8200092b5e60
To render the nested transforms properly, we need to store the inherited scale from ancestors for children.
Then apply the inherited scale for children's bounds
MozReview-Commit-ID: KYyibUD8J2j
--HG--
extra : rebase_source : fe2aeb842af477475767d0cf22c780c36b2487f0
To render the nested transforms properly, we need to store the inherited scale from ancestors for children.
Then apply the inherited scale for children's bounds
MozReview-Commit-ID: KYyibUD8J2j
--HG--
extra : rebase_source : 82c2695990e23eb47a4f185e0a53a865f3d1ff0f
