Instead of rendering a reference HTML page that wraps an <img> tag
pointing to a PNG, Screenshot tests now load the expected PNG directly
from disk and compare it against the rendered screenshot. This
eliminates the indirection of loading and rendering a second page just
to display a static image.
This also means --rebaseline now works for Screenshot tests, generating
the expected PNG automatically instead of requiring manual screenshot
capture and placement.
Changes:
- Add TestMode::Screenshot with its own collector and runner
- Move PNGs from Screenshot/images/ to Screenshot/expected/ with
normalized names matching input filenames
- Remove all 92 reference HTML wrapper files and the images/
directory
- Remove <link rel="match"> from all 94 Screenshot input HTML
files
- Update add_libweb_test.py Screenshot boilerplate accordingly
- Add Screenshot mode to results viewer image comparison tabs
Previously we didn't apply the value of `stroke-dasharray` if it was
`none`.
We also move resolution of this property into `ComputedProperties` in
line with other properties.
When rendering selections, we want to extend the selection rect for
wrapped lines to show that there is whitespace present. We don't
actually store this whitespace in the fragments; it's purely a visual
clue.
This reflects how both Chrome and Firefox deal with selection ranges
over wrapped lines.
Previously we wouldn't respect font-variation-settings for fonts matched
through `font_matching_algorithm` (i.e. any fonts which didn't have an
exact loaded match).
This allows Promises (including internal ones, like in Streams) and
FinalizationRegistry to work while scripting is disabled.
These were removed in the spec in support of WebDriver BiDi being able
to enable and disable scripting.
https://github.com/whatwg/html/commit/905b7218
This allows Fetch to work while scripting is disabled, due to its use
of Streams. This was noticeable if you disabled scripting in the UI,
or had a sandboxed iframe with scripting disabled.
There is more work to use job settings instead of realm inside these
hooks, but that's a separate issue.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/7409
Fixes https://github.com/LadybirdBrowser/ladybird/issues/3729
This fixes aliased edges when e.g. applying rotation transforms to
certain shapes or SVGs. Although the clip rects themselves are
rectangular, a non-identity matrix transform can be active for the
canvas.
Fixes#5909.
This changes Gfx::ScalingMode to reflect the three modes of scaling we
support using Skia, which makes it a bit easier to reason about the mode
to select. New is ::BilinearMipmap, which uses linear interpolation
between mipmap levels to produce higher quality downscaled images.
The cubic resampling options Mitchell and its sibling CatmullRom both
produced weird artifacts or resulted in a worse quality than
BilinearMipmap when downscaling. We might not have been using these
correctly, but the new ::BilinearMipmap method seems to mirror what
Chrome uses for downscaled images.
Integrates the new `FontVariationSettings` from LibGfx into LibWeb to
enable initial variable font functionality. Currently, only the `wght`
(weight) axis is fully supported and tested. This update also introduces
support for the CSS `font-variation-settings` property.
There's a fairly complicated interaction between an SVG gradient's paint
transformation and the gradient coordinate transformation required to
correctly draw gradient fills. This was especially noticeable when
scaling down an SVG, resulting in broken gradient coordinates and
graphical glitches.
This changes the objectBoundingBox units to immediately map to the
bounding box's coordinate system, so we can unify the gradient paint
transformation logic and make it a lot simpler. We only need to undo the
bounding box offset and apply the paint transformation to fix a lot of
gradient fill bugs.
We already had the API, but drawing to the canvas was not affected by
any created CanvasPattern. This moves CanvasPatternPaintStyle to LibGfx
so we don't have to reach into LibWeb, and implements the plumbing to
let Skia use images as a fill pattern.
Steps 4 and 5 were swapped since marking all the nodes between the start
and end of the selection now also marks the end node as full, even if it
should be marked as End.
There could be extra logic to avoid marking it if it is a text node, but
this seems easier.
As a whole, this fixes partially selected non-text nodes. In such cases,
where the selection starts or ends inside a node with descendants, it is
impossible to just select from the start node to the end node since that
would select all descendants of the start node and none of the end node.
Previously, this was only half considered and only if the start node was
a descendant of the end node.
Call paint_border() recursively, once for the outer line, and once for
the inner one. This is done in a lambda so that we can reuse it for a
couple of other line styles.
Border-radius behaviour doesn't match other browsers, and goes a bit
haywire in some cases. I've left some FIXMEs for someone who
understands the maths here better than I do. 😅
The LineStyle handling is moved to the start of the function, to avoid
unnecessary work.
FIXME: Rendering modifications to a list is sometimes not pixel-perfect
vs. reference (likely a bug). After this is fixed, screenshot
tests from this commit will likely fail + can be moved to
ref tests.
This test has flaked over the years, so let's add a screenshot test to
catch future regressions.
This copy of the test was taken from:
https://www.webstandards.org/files/acid2/test.html#top
Our CI infra does not support navigating to the "#top" anchor out of the
gate. So the intro section was removed from this copy so that we render
the happy face immediately.
We're able to efficiently draw repeated bitmaps through Skia, but for
backgrounds we only did so if the background was `repeat-x` _and_
`repeat-y`, and not if just one was set. This meant that for backgrounds
that were only repeating in one direction, we were taking the slow path.
Turns out that this slow path also produced graphical artifacts when
zooming in and out, so let's not do that :^)
Otherwise, the arrow painted next to the <details> element does not
update.
Using a screenshot test here because apparently the direction of the
arrow has no effect on the layout or paint trees.
This reverts commit a73cd88f0c.
Emitting SaveLayer for each paintable made rasterization a lot slower
on every website because now Skia has to allocate enormous amounts of
temporary surfaces. Let's revert it for now and figure how to implement
it with less aggressive SaveLayer usage.
When decoding data into bitmaps, we end up with different alpha types
(premultiplied vs. unpremultiplied color data). Unfortunately, Skia only
seems to handle premultiplied color data well when scaling bitmaps with
an alpha channel. This might be due to Skia historically only supporting
premultiplied color blending, with unpremultiplied support having been
added more recently.
When using Skia to blend bitmaps, we need the color data to be
premultiplied. ImmutableBitmap gains a new method to enforce the alpha
type to be used, which is now used by SharedResourceRequest and
CanvasRenderingContext2D to enforce the right alpha type.
Our LibWeb tests actually had a couple of screenshot tests that exposed
the graphical glitches caused by Skia; see the big smiley faces in the
CSS backgrounds tests for example. The failing tests are now updated to
accommodate the new behavior.
Chromium and Firefox both seem to apply the same behavior; e.g. they
actively decode PNGs (which are unpremultiplied in nature) to a
premultiplied bitmap.
Fixes#3691.
Before this change, an element masked with 'mask-image: url(...)' would
show the mask, but 'mask: url(...)' would not. On e.g. dialogic.nl it
would show white boxes instead of the actual images in the top
navigation bar. We still do not support many of the other mask
properties, but with this change at least the masks show up in both
cases.
SVGs are rendered with subpixel precision. As such it can happen that
paths are rendered with less than 1px width or height and that they can
have a bounding box thinner than 1px. Due to an optimization such paths
were ignored when painting because their bounding box was incorrectly
calculated to be empty.
As a result horizontal or vertical lines inside SVGs were missing if:
* The SVG is displayed at viewbox size but the lines are defined with
less than 1px.
* The SVG contians 1px-thin lines, but is displayed at a size smaller
than viewbox size.
To prevent this, the bounding box of the path is now enlarged to contain
all pixels that are partially affected.
In commit 1b82cb43c2 I accidentally
removed the paint transformation altogether. The result was that
zoomed-in SVGs, or SVG elements with a transformation applied could have
their gradient coordinates misplaced significantly.
This was also exposed in the `svg-text-effects` test by way of a slight
visual difference. Add a new test that very clearly exposes the fixed
issue by rotating the gradient coordinates by 45 degrees.
