This is a part of refactoring towards making the paintable tree
independent of the layout tree. Now, instead of transferring text
fragments from the layout tree to the paintable tree during the layout
commit phase, we allocate separate PaintableFragments that contain only
the information necessary for painting. Doing this also allows us to
get rid LineBoxes, as they are used only during layout.
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.
By storing painting command coordinates relative to the nearest
stacking context we can get rid of the Translate command.
Additionally, this allows us to easily check if the bounding
rectangles of the commands cover or intersect within a stacking
context. This should be useful if we decide to optimize by avoiding
the execution of commands that will be overpainted by the results of
subsequent commands.
This change separates the box outer shadow metrics calculations into a
separate function. This function is then used to obtain the shadow
bounding rectangle and skip painting if the entire shadow is outside
of the viewport.
This modification introduces a new layer to the painting process. The
stacking context traversal no longer immediately calls the
Gfx::Painter methods. Instead, it writes serialized painting commands
into newly introduced RecordingPainter. Created list of commands is
executed later to produce resulting bitmap.
Producing painting command list will make it easier to add new
optimizations:
- It's simpler to check if the painting result is not visible in the
viewport at the command level rather than during stacking context
traversal.
- Run painting in a separate thread. The painting thread can process
serialized painting commands, while the main thread can work on the
next paintable tree and safely invalidate the previous one.
- As we consider GPU-accelerated painting support, it would be easier
to back each painting command rather than constructing an alternative
for the entire Gfx::Painter API.
Before this change, we only blurred the shadows which would've been
generated without blur. This meant that we didn't generate a shadow when
the offset was zero, even with blur. However, other browsers generate a
shadow when blur is set.
Instead, always generate a rectangular contour of sufficient thickness,
blur it if needed and blit it into the right position at the very end.
Thanks to the blur radius, we'll have a shadow even when the offset is
zero.
Previously, calling `.right()` on a `Gfx::Rect` would return the last
column's coordinate still inside the rectangle, or `left + width - 1`.
This is called 'endpoint inclusive' and does not make a lot of sense for
`Gfx::Rect<float>` where a rectangle of width 5 at position (0, 0) would
return 4 as its right side. This same problem exists for `.bottom()`.
This changes `Gfx::Rect` to be endpoint exclusive, which gives us the
nice property that `width = right - left` and `height = bottom - top`.
It enables us to treat `Gfx::Rect<int>` and `Gfx::Rect<float>` exactly
the same.
All users of `Gfx::Rect` have been updated accordingly.
This fixes a few sizing issues too. The page size is now correct in most
cases! \o/
We get to remove some of the `to_type<>()` shenanigans, though it
reappears in some other places.
This fixes a rendering issue where box-shadows would not appear or
render completely broken if the blur radius was larger than the
border radius (border-radius < 2 * blur-radius to be exact).
This commit adds some finagling and shrinking of the corner bitmap
to handle drawing shadows on elements where the shadow radius >
half the width or height of the element. Previously things would
go horribly wrong when this happend.
There could still be some edge cases, but things seem to be working
fairly well now.
This now allows passing a 'fill_color' to the blur, any fully
transparent pixels will be replaced with this color (with the alpha
set to 0).
For box-shadows, if this color is set to the same as the shadow,
the issues around the fringes are fixed. This also fixes some places
where dark shadows appeared light / the wrong color.
With this change the blur no longer dominates the profile. On my PC
it is down to 27% (which is the same as the AA ellipse painting).
The box-shadow.html test page now also feels more responsive.
This commit adds support for using all your favorite border radii with
box-shadow, that is elliptical, circular, rounded rectangle etc. :^)
There is some work needed to make this more performant. The larger
your border radius is the larger the corner bitmap needs to be,
which means more time spent in FastBoxBlurFilter. There are probably
some tricks to bring this down.
Fixes#14325
This avoids a bunch of unnecessary work in Painter which not only took
time, but sometimes also led to alignment issues. draw_text_run() will
draw the text where we tell it, and that's it.
We don't yet take the spread-distance parameter into account, since we
don't have a way to "inflate" the text shadow.
Also, I'm not sure if we need to inflate the shadow slightly anyway.
Blurred shadows of our pixel fonts seem very faint. Part of this is
that a blur of < 3px does nothing, see #13231, but even so we might
want to inflate it a little.
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
Our previous code roughly did this:
1. Generate a bitmap as large as the shadow would end up.
2. Paint a rectangle onto it.
3. Blur the whole bitmap.
4. Split it up and render each section.
This patch takes advantage of the fact that (aside from corners) each
horizontal or vertical strip of a box-shadow is identical to the
others, to generate and blur a much smaller bitmap - only large enough
for the four corners and 1px of central "side" in each direction. This
greatly reduces the memory footprint, and should also speed things up,
since there is much less to blur.
We also pass whether the shadow goes inside or outside the element. Only
outer shadows are rendered currently, and inner ones may want to be
handled separately from them, as they will never interfere with each
other.
