Before this change AddClipRect was a "special" because it didn't respect
scroll frame offset and was meant to be recorded using viewport-relative
coordinates. The motivation behind this was to record a "final" clip
rectangle computed by intersecting all clip rectangles used by a clip
frame. The disadvantage of this approach is that it blocks us from
implementing an optimisation to reuse display list if the only change is
in the scroll offset, because any scroll offset change leads to
invalidating all AddClipRect items within a list.
This change aligns AddClipRect with the rest of display list items by
making it account for scroll frame offset. It required discontinuing
the recording of the intersection of all clip rectangles within a clip
frame and instead producing an AddClipRect for each of them.
A nice side effect is the removal of code that shifts clip rectangle by
`enclosing_scroll_offset()` in a bunch of places, because now it happens
automatically in `DisplayList::apply_scroll_offsets()`.
While introducing clip and scroll frame trees, I made a mistake by
assuming that the paintable tree includes boxes from nested navigables.
Therefore, this comment in the code was incorrect, and clip/scroll
frames were simply not assigned for iframes:
// NOTE: We only need to refresh the scroll state for traversables
// because they are responsible for tracking the state of all
// nested navigables.
As a result, anything with "overflow: scroll" is currently not
scrollable inside an iframe
This change fixes that by ensuring clip and scroll frames are assigned
and refreshed for each navigable. To achieve this, I had to modify the
display list building process to record a separate display list for each
navigable. This is necessary because scroll frame ids are local to a
navigable, making it impossible to call
`DisplayList::apply_scroll_offsets()` on a display list that contains
ids from multiple navigables.
This refactoring makes WebContent less aware of LibWeb internals.
The code that initializes paint recording commands now resides in
`Navigable::paint()`. Additionally, we no longer need to reuse
PaintContext across iframes, allowing us to avoid saving and restoring
its state before recursing into an iframe.
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.
This fixes an issue where the value would be out of sync with reality
in anonymous wrapper block boxes, since we forgot to compute m_visible
after assigning the computed values to them.
Fixes#21106
The "browsing context container" concept in the HTML spec has been
replaced with "navigable container". Renaming this is the first step of
many towards implementing the new world.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
The name "initial containing block" was wrong for this, as it doesn't
correspond to the HTML element, and that's specifically what it's
supposed to do! :^)
This simplifies the ownership model between DOM/layout/paint nodes
immensely by deferring to the garbage collector for figuring out what's
live and what's not.
This fixes a few sizing issues too. The page size is now correct in most
cases! \o/
We get to remove some of the `to_type<>()` shenanigans, though it
reappears in some other places.
This patch adds a bunch of Paintable subclasses, each corresponding to
the Layout::Node subclasses that had a paint() override. All painting
logic is moved from layout nodes into their corresponding paintables.
Paintables are now created by asking a Layout::Box to produce one:
static NonnullOwnPtr<Paintable> Layout::Box::create_paintable()
Note that inline nodes still have their painting logic. Since they
are not boxes, and all paintables have a corresponding box, we'll need
to come up with some other solution for them.
