Text decorations have a special kind of propagation. Instead of
propating these during box tree construction, move propagation to
stacking context tree construction. This will allow for using a very
easy type of incremental layout when text decorations change. For
instance, when a link changes color during hovering over it, we can skip
all of box and fragment tree construction.
In addition, propagation works a bit better now and color and style
properly move down from their originating `Fragment`s.
This introduces three new failures, because now we are drawing the
text-decoration with the correct color in more places, which exposes an
issue we have with text-decorations not being drawn in relation to the
baseline (taking into account `vertical-align`).
Testing: There are tests for these changes.
Fixes#31736.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
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>
Instead of resolving the canvas background properties (essentially
keeping a possible reference to the `<body>`'s style) during fragment
tree construction, wait until painting to possibly find the style on an
appropriate `<body>` fragment. This is possible now because `Fragment`
keeps a list of flags with relevant information about the root and
`<body>` elements.
A benefit of this approach is that styles aren't cached in the fragment
tree, which would be problematic for incremental layout. In addition,
the old code was making an effort to transform the `<body>`'s background
by the root element's transform. Only Safari does this and there was
a resolution the WG that this should not happen in
https://github.com/w3c/csswg-drafts/issues/6683.
Testing:
- `/css/css-transforms/transform-translate-background-001.html`
- `/css/css-transforms/transform-translate-background-002.html`
- `/css/CSS2/floats/float-root.html`
Fixes: #30475.
Closes: #30569.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
In the scrollable overflow calcutation, apply CSS transforms to boxes
and scrollable overflow of the descendant. Clip unreachable scrollable
overflow according to it's block start and inline start scrolling
direction. And, renamed `Fragment::scrolling_overflow` to
`Fragment::scrolling_overflow_for_parent` as it was calculating the
scrolling overflow contribution from a child.
Add several WPT tests, testing the transform interaction `rotate`,
`scale`, and `skew` with scrollable overflow. There are several WPT test
that are testing the interaction that not expected from current browsers
implementation according to the spec.
Testing: Existing and new WPT.
Fixes: #36031
---------
Signed-off-by: stevennovaryo <steven.novaryo@gmail.com>
Instead of grouping all the `will-change` conditions together, move each
one of them next to the condition for the relevant property.
This avoids the need to call `is_transformable()` multiple times, and
will also be needed for #35391.
Testing: unneeded (no change in behavior)
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Now that legacy layout has been removed, the name `layout_2020` doesn't
make much sense any longer, also it's 2025 now for better or worse. The
split between the "layout thread" and "layout" also doesn't make as much
sense since layout doesn't run on it's own thread. There's a possibility
that it will in the future, but that should be something that the user
of the crate controls rather than layout iself.
This is part of the larger layout interface cleanup and optimization
that
@Looriool and I are doing.
Testing: Covered by existing tests as this is just code movement.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
2025-04-19 10:17:03 +00:00
Renamed from components/layout_2020/display_list/stacking_context.rs (Browse further)
