This change is a preparation before introducing Skia painter in an
upcoming change. It's needed because Skia does not have an API to
implement ClearClipRect command. It only allows to return previous
clip rect by popping from its internal state stack.
A bit more context: initially we had save and restore commands, but
their frequent use led to many reallocations of vector during painting
commands recording. To resolve this, we switched to SegmentedVector to
store commands list, which allows fast appends. Now, having many save
and restore commands no longer causes noticeable performance issue.
This adds two new CommandResults: ContinueWithNestedExecutor and
ContinueWithParentExecutor.
ContinueWithNestedExecutor switches the command executor to the result
of calling `.nested_executor()` on the current CommandExecutor.
ContinueWithParentExecutor returns to the previous command executor
(i.e. what it was before the last ContinueWithNestedExecutor).
`Painting::paint_all_borders()` only uses `.draw_line()` for simple
borders and `.fill_path()` for more complex cases. These are both
already supported by the `RecordingPainter` so removing this command
simplifies the painting API.
Two test changes:
css-background-clip-text: Borders are now drawn via the AA painter
(which makes them closer to how they appear in other browsers).
corner-clip-inside-scrollable: Borders removed (does not change test)
due to imperceptible sub-pixel changes.
...instead of allocating separate BorderRadiusCornerClipper for each
executed sample/blit commands pair.
With this change a vector of BorderRadiusCornerClipper has far fewer
items. For example on twitter profile page its size goes down from
~3000 to ~3 items.
For bitmap fonts, we will often not have an exact match for requested
sizes. Return the closest match instead of a nullptr.
LibWeb is currently the only user of this API. If it needs to be
configurable in the future to only allow exact matches, we can add a
parameter or another method at that time.
Before this change we were recording and executing sample/blit commands
for each painting phase, even if there are no painting commands
in-between sample and blit that produce result visible on a canvas.
This change adds an optimization pass that goes through recorded
painting commands list and marks sample and blit commands that could
be skipped.
Reduces sample and blit corners executing from 17% to 8% on Discord.
PaintFrame is not primitive painting command, we inherited from OS, that
is hard to replicate in GPU-painter or alternative CPU-painter API. We
should remove it as a part of refactoring towards simplifying recording
painter commands set.
Fixes: #23796
From https://drafts.csswg.org/css-backgrounds-4/#background-clip
"The background is painted within (clipped to) the intersection of the
border box and the geometry of the text in the element and its in-flow
and floated descendants"
This change implements it in the following way:
1. Traverse the descendants of the element, collecting the Gfx::Path of
glyphs into a vector.
2. The vector of collected paths is saved in the background painting
command.
3. The painting commands executor uses the list of glyphs to paint a
mask for background clipping.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
...to avoid allocating a copy of glyph run for painting commands. We
can't simply save pointers to a glyph run in layout/paintable tree
because it should be safe to deallocate layout and paintable trees
after painting commands are recorded, if in the future we decide to
move command execution to a separate thread.
Instead of allocating a new glyph run to scale glyph positions and
fonts, a scale factor could be encoded in a paint command and applied
later during command execution.
Instead of allocating a new glyph run solely to shift each glyph by the
painter's offset, this offset could be encoded in a paint command and
applied later during command execution.
Painting command executors are defined within the "Painting" namespace,
allowing us to remove this prefix from their names.
This commit performs the following renamings:
- Painting::PaintingCommandExecutor to Painting::CommandExecutor
- Painting::PaintingCommandExecutorCPU to Painting::CommandExecutorCPU
- Painting::PaintingCommandExecutorGPU to Painting::CommandExecutorGPU
Separating the recorder list from the painter will allow us to save it
for later execution without carrying along the painter's state. This
will be useful once we have a separate thread for executing painting
commands, to which we will have to transfer commands from the main
thread.
Preparation for https://github.com/SerenityOS/serenity/pull/23108