This allows for:
* Transformed text (e.g. rotated text)
* Stroked text
* Filling/stroking text with PaintStyles (e.g. gradients)
* Squashed/condensed text (via maxWidth parameter)
Fixes part of #22817
With this change, instead of applying only the border-radius clipping
from the closest containing block with hidden overflow, we now collect
all boxes within the containing block chain and apply the clipping from
all of them.
We don't currently calculate the fill- or stroke-boxes of SVG elements,
so for now we use the content- and border-boxes respectively, as those
are the closest equivalents. The test will need updating when we do
support them.
Also, the test is a screenshot because of rendering differences when
applying transforms: a 20px box does not get painted the same as a 10px
box scaled up 2x. Otherwise that would be the more ideal form of test.
This refactoring makes WebContent less aware of LibWeb internals.
The code that initializes paint recording commands now resides in
`Navigable::paint()`. Additionally, we no longer need to reuse
PaintContext across iframes, allowing us to avoid saving and restoring
its state before recursing into an iframe.
This patch makes a few changes to the way we calculate line-height:
- `line-height: normal` is now resolved using metrics from the used
font (specifically, round(A + D + lineGap)).
- `line-height: calc(...)` is now resolved at style compute time.
- `line-height` values are now absolutized at style compute time.
As a consequence of the above, we no longer need to walk the DOM
ancestor chain looking for line-heights during style computation.
Instead, values are inherited, resolved and absolutized locally.
This is not only much faster, but also makes our line-height metrics
match those of other engines like Gecko and Blink.
Previously, these were clipped by the RecordingPainter, which used the
path's bounding box (which in this case is zero width or height). The
fix is to expand the bounding box by the stroke width.
Fixes#22661
Note: This is unrelated to any recent LibGfx changes :^)
CSSPixels should not be wrapped into CSS::Length before being passed
to resolved() to end up resolving percentages without losing
precision.
Fixes thrashing layout when 33.3333% width is used together with
"box-sizing: border-box".
This avoids doing pointless plotting for scanlines that will never be
seen.
Note: This currently can only clip edges vertically. Horizontal clipping
is more tricky, since edges that are not visible can still change how
things accumulate across the scanline.
Fixes#22382
Sadly, this causes a bunch of LibWeb test churn as this change
imperceptibly changes the final rasterized output.
The css-backgrounds.html ref test file only tests the most basic usage
of this, which failed to catch some regressions, so let's add a more
extensive test. :^)
Given that we have a glyph run where the position of each glyph is
calculated for text fragments during layout, we can reuse it to avoid
this work during painting.
Previously, we determined the positions of glyphs for each text run at
the time of painting, which constituted a significant portion of the
painting process according to profiles. However, since we already go
through each glyph to figure out the width of each fragment during
layout, we can simultaneously gather data about the position of each
glyph in the layout phase and utilize this information in the painting
phase.
I had to update expectations for a couple of reference tests. These
updates are due to the fact that we now measure glyph positions during
layout using a 1x font, and then linearly scale each glyph's position
to device pixels during painting. This approach should be acceptable,
considering we measure a fragment's width and height with an unscaled
font during layout.
This is an adaptation of the "misc/backgrounds.html" file in the
Serenity image. It tests a lot of background-related properties that we
otherwise have no tests for.
This makes use of the new Gfx::Path::text() to handle SVG text elements,
with this text is just a regular path, and can be manipulated like any
other graphics element.
This removes the SVGTextPaintable and makes both <text> and geometry
elements use a new (shared) SVGPathPaintable. This is identical to the
old SVGGeometryPaintable. This simplifies painting as once something is
resolved to a Gfx::Path, the painting logic is the same.
This is based on the border-radius.html demo page with text and most
assets removed. This has to be a screenshot based test as there's not
really something else that can be used for comparison.
This also makes the test a little incomplete as things like text
overflow clipping are not tested, but I'd like to avoid this test being
too brittle.
Each ref test now links to its reference page with a link tag, in the
same format as WPT:
`<link rel="match" href="reference-page.html" />`
The reference pages have all been moved into a separate `reference/` dir
so that we can just treat every file in `ref/` as a test. There's no
filter to only look at .html files, because we also have a .svg file in
there, and there may be other formats we want to use too. But it's not
too hard to add one if we need it.
