These allow you to specify the point were the gradient transitions
from one color to the next (without a transition hint the transition
occurs at the point 50% of the way between the two colors).
There is a little bit of guesswork in this implementation as the
specification left out how hints work with the color stop fixup,
though it appears that they are treated the same as color stops.
This commit moves both the ImageStyleValue and LinearGradientStyleValue
to a common base class of AbstractImageStyleValue. This abstracts
getting the natural_width/height, loading/resolving, and painting
the image.
Now for 'free' you get:
- Linear gradients working with the various background sizing/repeat
properties.
- Linear gradients working as list-markers :^) -- best feature ever!
P.s. This commit is a little large as it's tricky to make this change
incrementally without breaking things.
This makes them look a bit more like a progress bar, especially
on white backgrounds (for the default theme) where you otherwise
cannot see the unfilled part of the bar.
This is mainly so we can easily read that matrix later, but also has the
benefit of only calculating the matrix once, instead of every time we
paint. :^)
Also, made the `reference_length` parameter optional for the lambda that
extracts transform-function parameters, since it is only needed to
resolve `LengthPercentage` parameters.
This now calls before/after_child_paint() on the parent paintable
of a positioned child. This allows the parent's overflow clipping
to apply to the child.
Previously, before/after_children_paint() was only called for the
"Foreground" paint phase, this meant the backgrounds and other
features of child nodes of a element with overflow: hidden were
not clipped.
This implements support for painting linear-gradients in a spec
correct way :^).
Right now it supports:
- Multi-stop gradients
- Color stop fixups
- Using pre-multiplied alpha mixing when required
- Painting gradients at arbitrary angles
It still needs to support:
- Transition hints
- Double position color stops
However what is implemented now seems to be accurate to other
browsers, and covers the most common use cases.
This is just a quick test that everything is working. Currently
it paints the gradients with the existing
painter.fill_rect_with_gradient(). This can only handle two-color
orthogonal gradients.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This a simple RAII helper for the BorderRadiusCornerClipper it
samples under the corners on construction, then blits them back
on exiting the scope. This encapsulates a fairly common pattern.
Note: With this change the border-radius is clipped if ethier the
overflow-x or overflow-y is hidden (it is a little unclear what
happens if just one is set, but it seems like most browsers
treat one set + border-radius the same as if overflow: hidden
was set).
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 fixes a issue due to the background/border painting using
.to_rounded<int>() to get an IntRect, but shadow painting was using
enclosing_int_rect().
enclosing_int_rect() uses some floors/ceils and does not always match
.to_rounded<int>().
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
Previously, this was slightly off and not doing what the spec comment
above asked for. This led to really small values for x_step and
y_step, making the `backgrounds.html' example use crazy amounts of
CPU whist painting.
