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.
Previously we forwarded all event handler attributes to Window from
these two elements, however, we are only supposed to forward blur,
error, focus, load, resize and scroll.
This allows HTMLCanvasElement and WebGL rendering contexts to share
their lifetime, as JS allows them to arbitrarily access them at any
time and WebGLRCB.canvas expects a non-null return value.
This allows HTMLCanvasElement and CRC2D to share their lifetime, as JS
allows them to arbitrarily access them at any time and CRC2D.canvas
expects a non-null return value.
To achieve this goal:
- The Browser unveils "/tmp/portal/filesystemaccess"
- Pass the page through LoadRequest => ResourceLoader
- ResourceLoader requests a file to the FileSystemAccessServer via IPC
- OutOfProcessWebView handles it and sends a file descriptor back to
the Page.
The lack of the commit() before returning the x_value here meant,
that in parse_background_value() the token stream would be one token
behind after parsing the background-size. This led to it to returning
null, after it sees the unexpected 'second' contain / cover token.
With this change all of backgrounds.html is working again.
This prevents font-face rules without a block statement from crashing
LibWeb during CSS parsing.
The issue was discovered by Lubrsi during CSS parser fuzzing. :)
Fixes#14141.
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
We were not applying the distributed space to the used offset of flex
items, as we were only assigning the margins to the layout state of the
box, not the internal FlexItem::margins.
Before we ask a replaced box about its intrinsic dimensions, we have
to "prepare" the box, which tells it to go and work out what its
intrinsic dimensions are.
I've added a FIXME about how this is silly (and clearly bug-prone)
but this patch only patches it locally in FFC for now.
Used by Google seemingly almost all around account sign in and
management. The modern sign in page has this near the beginning:
```html
<base href="https://accounts.google.com">
```
All of the XHRs performed by sign in are relative URLs to this
base URL. Previously we ignored this and did it relative to the
current URL, causing the XHRs to 404 and sign in to fall apart.
I presume they do this because you can access the sign in page
from multiple endpoints, such as `/ServiceLogin` and
`/o/oauth2/auth/identifier`
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.
From the spec:
> This property previously accepted the values optimizeSpeed and
optimizeQuality. These are now deprecated; a user agent must accept
them as valid values but must treat them as having the same behavior
as pixelated and smooth respectively, and authors must not use them.
- https://www.w3.org/TR/css-images-3/#the-image-rendering
It's probably not in 1:1 as spec says, as it wants us to first upscale
the image to the nearest integer and then downscale it bilinearly.
But this mode still falls into the general description of the value:
> The image is scaled in a way that preserves the pixelated nature of
> the original as much as possible, but allows minor smoothing instead
> of awkward distortion when necessary.
Also, this way we don't have to allocate the memory just for the integer
scale. :^) :^)
This is a helper class for clipping the corners off a element.
This works in a similar way to how (outline) borders are painted.
The steps are:
1. A small bitmap that fits only the corners is allocated
2. The corners are painted into the bitmap
3. The existing pixels (where the corners will be painted)
are copied using the (inverse) corner bitmap as a mask
(done before the element is painted)
4. The element is painted
5. The areas outside the corner radii are restored
Like with the borders, this only requires allocation on the first
paint.
Implement parsing of rgb(..) and hsl(..) in both the modern level 4
syntax without commas, and the legacy syntax with commas.
The parser accepts non-integer numbers but rounds to integer values
for now.
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.
