This gets rid of the assumption that the DOM node of an ImageBox is
also its image provider. This will become necessary when generating
the image boxes for view transition pseudos, for which the DOM node
won't be the image provider. (that'll be the pseudo element itself)
As it turns out, SkPath already behaves the way we need for SVG and HTML
canvas elements. Less work for us, yay! This removes a 5% item from the
profile when scrolling on https://imdb.com/
Note that there's a tiny screenshot test expectation change due to
minor antialiasing differences when we no longer do our redundant
subpath modifications.
This makes it so that the bounds for any paint-contained stacking
context are not derived from its children, but rather just set to
the rectangle that they will be clipped to anyways due to the paint
containment. Should make rendering faster on pages that use paint
containment.
This is required because bounding rect used in `saveLayer()` is computed
in stacking context's coordinate space.
Fixes regression introduced in ba2926f
Instead of resolving some viewport-relative sizes on every paint, we now
do them just once in paint-only property update.
This takes SVGPathPaintable::paint() from 15% to 8% in the profile when
scrolling on https://imdb.com/
Before this change, we always updated paint-only properties for every
single paintable after layout or style changes.
This could get very expensive in large documents, so this patch makes
it something we can do partially based on "repaint" invalidations.
This cuts down time spent in paint-only property update when scrolling
https://imdb.com/ from 19% to 5%.
These functions are trivial, and we were actually bleeding a lot of time
in profiles to just function entry/exit.
By marking Length::make_px() as [[nodiscard]], we also exposed some
places that were creating a Length and not using it for anything.
Before this change, we were basically always setting the non-initial
border radii flag on ComputedValues, which made the work-avoiding
optimization based on this flag ineffective.
Teach the display list executor to derive a bounding rectangle for
stacking contexts whose inner commands can all report bounds, that is,
most contexts without nested stacking contexts.
This yields a large performance improvement on https://tc39.es/ecma262/
where the display list contains thousands of groups like:
```
PushStackingContext blending=Multiply
DrawGlyphRun
PopStackingContext
```
Previously, `PushStackingContext` triggered an unbounded `saveLayer()`
even when the glyph run lies wholly outside the viewport. With this
change, we (1) cull stacking contexts that fall outside the viewport and
(2) provide bounds to `saveLayer()` when they are visible.
With this change rendering thread goes from 70% to 1% in profiles of
https://tc39.es/ecma262/. Also makes a huge performance difference on
Discord.
We have a slightly odd setup here. TransformationStyleValue reifies as a
single CSSTransformComponent. It's StyleValueList that actually reifies
as a CSSTransformValue - but only if it only contains
TransformationStyleValues.
+79 WPT subtests.
This is the final CSSStyleValue class used by the per-property test
harness, so those now actually run instead of throwing an exception on
load. 🎉
+39 WPT subtests. (Plus however many from the per-property tests finally
running.)
The two failing serialization tests are also failed by Safari in exactly
the same way, so that seems more like a spec issue. (The spec is
incomplete in quite a few places.) The failing subtest for toMatrix() is
also a spec issue: is2D is handled oddly by CSSMatrixComponent and this
subtest fails because of the `matrix` getter, which is unspecified. See
https://github.com/w3c/css-houdini-drafts/issues/1155 for details.
DOMMatrix.to_string() throws exceptions if any of its values are
non-finite. This ends up affecting CSSStyleValue because its subclass
CSSTransformValue (which is about to be added) serializes
CSSTransformComponents, and one of those is CSSMatrixComponent, which
calls DOMMatrix.to_string().
This is all quite unfortunate, and because at the time the spec for
DOMMatrix was written, CSS couldn't represent NaN or infinity. That's
no longer true, so I'm hoping the spec can be updated and this can be
reverted. https://github.com/w3c/fxtf-drafts/issues/611
Equivalent to the perspective() transform function.
+34 WPT subtests, and the transformvalue-normalization test now runs to
completion instead of throwing an error - though its cases still fail
until CSSTransformValue is implemented.
