When recording the display list for a stacking context, the following
operations (relevant to this bug) happened:
* push a stacking context
* as part of that push a None-value to the scroll frame id stack
* apply filters
* apply masking
* paint recursively
This meant that mask-images were always recorded without scroll frame
id, causing them to be painted without any scroll offset. As a result
mask-images would break as soon as the website using them was scrolled.
Instead, push to the scroll frame id stack later to solve the problem:
* push a stacking context
* apply filters
* apply masking
* push a None-value to the scroll frame id stack
* paint recursively
With this change we save a copy of of scroll state at the time of
recording a display list, instead of actual ScrollState pointer that
could be modifed by the main thread while display list is beings
rasterized on the rendering thread, which leads to a frame painted with
inconsistent scroll state.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/4288
This adds a command for saving the current layer of the canvas.
This is useful for painting content onto a blank background in
isolation and later compositing it onto the canvas.
Instead of trying to manually determine which parts of a bitmap fall
within the box of the `<img>` element, just draw the whole bitmap and
let Skia clip the draw-area to the correct rectangle.
This fixes a bug where the entire bitmap was squashed into the rectangle
of the image box instead of being clipped.
With this change, image rendering is now correct enough to import some
of the WPT tests for object-fit and object-position. To get some good
coverage I have imported all tests for the `<img>` tag. I also wanted to
import a subset of the tests for the `<object>` tag, since those are
passing as well now. Unfortunately, they are flaky for unknown reasons.
This is the second attempt at this bugfix. The prior one was e055927ead
and broke image rendering whenever the page was scrolled. It has
subsequently been reverted in 16b14273d1. Hopefully this time it is not
horribly broken.
Instead of trying to manually determine which parts of a bitmap fall
within the box of the `<img>` element, just draw the whole bitmap and
let Skia clip the draw-area to the correct rectangle.
This fixes a bug where the entire bitmap was squashed into the rectangle
of the image box instead of being clipped.
With this change, image rendering is now correct enough to import some
of the WPT tests for object-fit and object-position. To get some good
coverage I have imported all tests for the `<img>` tag. I also wanted to
import a subset of the tests for the `<object>` tag, since those are
passing as well now. Unfortunately, they are flaky for unknown reasons.
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.
This improves the quality of our font rendering, especially when
animations are involved. Relevant changes:
* Skia fonts have their subpixel flag set, which means that individual
glyphs are rendered at subpixel offsets causing glyph runs as a
whole to look better.
* Fragment offsets are no longer rounded to whole device pixels, and
instead the floating point offset is kept. This allows us to pass
through the floating point baseline position all the way to the Skia
calls, which already expected that to be a float position.
The `scrollable-contains-table.html` ref test needed different table
headings since they would slightly inflate the column size in the test
file, but not the reference.
CSS filters work similarly to canvas filters, so it makes sense to have
Gfx::Filter that can be used by both libraries in an analogous way
as Gfx::Color.
