This change fixes a problem that we should not call `to_px()` to
resolve any length or percentage values during paintables traversal
because that is supposed to happen while performing layout.
Also it improves performance because before we were resolving border
radii during each painting phase but now it happens only once during
layout.
Currently, in CPU painter, border painting is implemented by building
a Gfx::Path that is filled by Gfx::AntiAliasingPainter. In the GPU
painter, we will likely want to do something different, and with a
special command, it becomes possible.
Also, by making this change, the CPU executor also benefits because now
we can skip building paths for borders that are out of the viewport.
By consistently accepting only device pixel values instead of a mix of
CSSPixels and DevicePixels values, we can simplify the implementation
of paint_border() and paint_all_borders().
With the recording painter the actual painting operations are delayed,
so now if multiple corner clippers are constructed, and they use a
shared bitmap they can interfere with each other. The use of this shared
bitmap was somewhat questionable anyway, so this is not much of a loss.
This fixes the border-radius.html test page.
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.
Previously, the corner overlap algorithm implementation did not shrink
the border radii for zero width/height boxes, which resulted in
incorrect painting.
With this the implementation is updated to more closely follow the spec
steps, which naturally handles the zero width/height case. This makes
use of the `CSSPixelFraction` class for lossless comparison and
multiplication of the scaling factor for the radii.
Co-authored-by: Zaggy1024 <Zaggy1024@gmail.com>
Build a grid snapped to device pixels and use it to construct the
rectangles for the cell edges, same as for collapsed borders. This is
especially important when border-spacing is set to 0 since it avoids
gaps between adjacent cells which have borders set.
...along with `outline-color`, `outline-style`, and `outline-width`.
This re-uses the existing border-painting code, which seems to work well
enough!
This replaces the previous code for drawing focus-outlines, with generic
outline painting for any elements that want it. Focus outlines are now
instead supported by this code in Default.css:
```css
:focus-visible {
outline: auto;
}
```
The `clip_shrink` optimization in `paint_background()` now also
correctly uses DevicePixels, instead of reducing a DevicePixel rect by
a CSSPixels amount.
When joined border width is zero width, then the midpoint
of the joined corner is no longer need to be computed
anymore. Just set the mid point to be the endpoint of the
corner.
Fixes broken border-radius painting because of lost precision while
converting back and forth between double and CSSPixels.
Fixed example:
```html
<style>
div {
border-radius: 9999px;
background: orange;
padding: 10px;
}
</style><div>huh</div>
```
The refactor of the border painting mainly to handle:
1. Single border with minor border radius.
2. Different border widths and border colors joined situations.
This refactor only apply to solid border.
The main differece is to use Path.fill to paint each border,
not fill_rect anymore. There's a special case need to consider.
The Path.fill will leave shared edge blank between two borders.
To handle this, we decide to combine the borders with same color
to paint together.
Although DistinctNumeric, which is supposed to abstract the underlying
type, was used to represent CSSPixels, we have a whole bunch of places
in the layout code that assume CSSPixels::value() returns a
floating-point type. This assumption makes it difficult to replace the
underlying type in CSSPixels with a non-floating type.
To make it easier to transition CSSPixels to fixed-point math, one step
we can take is to prevent access to the underlying type using value()
and instead use explicit conversions with the to_float(), to_double(),
and to_int() methods.
This fixes a plethora of rounding problems on many websites.
In the future, we may want to replace this with fixed-point arithmetic
(bug #18566) for performance (and consistency with other engines),
but in the meantime this makes the web look a bit better. :^)
There's a lot more things that could be converted to doubles, which
would reduce the amount of casting necessary in this patch.
We can do that incrementally, however.
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 commit reimplements the (normally) 45 degree (depends on
the widths) connection between to adjacent borders. Which is
needed to paint the 'caret' icon seen in a few buttons on GitHub.
The issue of overlapping pixels while painting this has also
been solved for the 45 degree case (the the most likely case,
the other cases only occur of mixed-with borders).
This commit adds some much nicer border painting, which now supports:
- Elliptical corners
- Blending between different border thicknesses, with rounded corners
- Anti-aliasing
There are some little TODOs left to tackle:
- Painting the corners with line styles other than solid
- Blending between colors on the corners (see comments)
The painting requires allocating a small bitmap, that only fits the
corners (so in most cases this is very small).
This bitmap is then cached so for all paints but the first there will
be no further allocations.
By using enclosing_int_rect(), borders and backgrounds of boxes were
sometimes 1 pixel off, making things slightly larger than they should
be. Fix this by using to_rounded() instead of enclosing_int_rect().
There's definitely more of these type of issues lurking in the code,
and we'll get to them in time.
Rather than dividing the rect width and high by the border lengths,
this change multiples those lengths by the reciprocal of the width
and height because this is a faster operation. When mousing around on
the html spec website, the profile showed that inline painting
went from ~15% to ~3%
Nobody makes undefined Lengths now, (although actually removing
Undefined will come in a later commit) so we can remove this parameter,
and `resolved_or_auto()`/`resolved_or_zero()`.
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
This is a bit of a hack to get box content to stop bleeding 1px outside
the border sometimes. We will need to come up with a more general
solution for this problem eventually.
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
The logic here is needed by InlineNode too. Moving it into a
`paint_all_borders()` function makes it available to them both, as well
as anyone else who wants it. :^)
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
