layout: Split stacking context and display list construction (#37047)

Previously, after a layout was finished (or skipped in the case of
repaint-only layout), both the stacking context tree and display list
were built. In the case of repaint-only layout, we should be able to
skip the reconstruction of the stacking context tree and only do display
list building.

This change does that, also generally cleaning and up and clarifying the
data structure used during this phase of layout. This opens up the
possibility of a new kind of incremental layout that does both repaint
and a rebuild of the stacking context tree.

On the blaster.html test case[^1], this reduces tightly-measured layout
time from ~45-50 milliseconds to ~25-30 milliseconds on my M3.

[^1]: https://gist.github.com/mrobinson/44ec87d028c0198917a7715a06dd98a0

Testing: There are currently no performance tests for layout. :( This
should
not modify the results of WPT tests.

Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This commit is contained in:
Martin Robinson 2025-05-20 15:42:39 +02:00 committed by GitHub
parent 27c8a899ea
commit d8294fa423
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
13 changed files with 967 additions and 789 deletions

View file

@ -92,7 +92,7 @@ pub(crate) struct BoxFragment {
pub scrollable_overflow_from_children: PhysicalRect<Au>,
/// The resolved box insets if this box is `position: sticky`. These are calculated
/// during stacking context tree construction because they rely on the size of the
/// during `StackingContextTree` construction because they rely on the size of the
/// scroll container.
pub(crate) resolved_sticky_insets: AtomicRefCell<Option<PhysicalSides<AuOrAuto>>>,