Currently, we just rebuild boxes for all nodes from the update point
downward, and the unique valid candidates as update point is just the
absolutely positioned ancestor of the style recalc dirty dom root node.
It is quite crude way for incremental box tree update and incremental
layout, because it will lead to a lot of boxes to be rebuilt even though
their originating nodes have no style change, i.e. only some child nodes
are newly added or removed. Meanwhile, all cached fragments need to be
invalidated from the update point downward, even though there is no any
change of the layout constraits and containing block for some of those
rebuilt boxes.
To preserve more boxes and cached fragments as much as possible, this PR
try to rebuild those boxes whose originating node has `REBUILD_BOX`
restyle damage and try to repair those boxes whose originating node has
`REPAIR_BOX` damage. It is a relative big task. To implement it step by
step, this PR only repair and reuse the block level boxes. In the future,
the others kind of boxes will be repaired or reused.
Signed-off-by: coding-joedow <ibluegalaxy_taoj@163.com>
Instead of computing scrollable overflow while constructing the fragment
tree, we will now do it later. In the future this will also allow to
only recalculate the overflow without rebuilding the tree when transform
properties change, but that's left for a follow-up.
Stylo PR: https://github.com/servo/stylo/pull/194
Testing: One test is now passing (more investigation is needed), but
otherwise this isn't expected to have any effect.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
This fixes an issue where a viewport change did not trigger a reflow,
when the restyle damage was was otherwise REPAINT. Viewport changes
mean changes to the initial containing block, which is one of the main
inputs to layout. This should trigger a reflow always.
Testing: Unfortunately, our testing infrastructure is not good enough
yet
to test changes to layout when resizing the `WebView`, so it is quite
difficult to write tests for this change.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
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>
When making last-minute changes to the repaint-only layout pass, damage
propagation was broken, meaning that full layout was always done. This
change fixes that, meaning that times in the `blaster.html` test case
now reflect those described in the original commit message from #36978.
In addition, some style repair is now fixed:
- `InlineFormattingContext`s now keep a `SharedInlineStyles` for the
root of the IFC
which is updated during style repair.
- `BlockFormattingContext`s now properly update their style.
These changes are verified by turning on repaint only layout for more
properties
in Stylo via servo/stylo#183.
Testing: Manual performance testing via `blaster.html`.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Before this patch it wasn't possibly to simultaneously support intrinsic
min/max sizes and content alignment in the block axis. For example,
block containers only support the former, and flex containers only the
latter.
The reason is that the final block size was decided by the parent
formatting context *after* performing layout, while content alignment is
performed *during* layout.
To address the problem, this introduces the struct `LazySize`, which
contains the data to resolve the final size, except for the intrinsic
size. Thus the parent formatting context can first create a `LazySize`,
then pass it to the child layout so that (if necessary) it can compute
the final size once the intrinsic one is known, and after layout the
parent formatting context uses it to actually size the child.
This PR just provides the functionality that will be used by follow-ups,
but at this point no layout is using the `LazySize` provided by the
parent, so there shouldn't be any behavior change yet.
Testing: Unnecessary (no behavior change)
This is part of #36981 and #36982
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
This change adds the simplest kind of incremental layout. When Servo
detects that all style changes only require a repaint, only run stacking
context tree and WebRender display list generation. This means that
these kind of restyles do not need a re-layout. Instead, the existing
box and fragment trees will be used and the styles of damaged nodes will
be updated in their box and fragment tree nodes.
This requires a new style repair DOM traversal for nodes that have had
their style damaged. In addition, careful accounting of all the places
where we store style must happen in order ot update those styles.
Testing: This is covered by existing WPT tests as it should not change
observable behavior.
We have created a test case which shows a 50% speedup when run
in Servo, even though there still a long way to go to match the speed
of other browsers:
https://gist.github.com/mrobinson/44ec87d028c0198917a7715a06dd98a0
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
`TextRun`s use their parent style to render. Previously, these styles
were cloned and stored directly in the box tree `TextRun` and resulting
`TextFragment`s. This presents a problem for incremental layout.
Wrapping the style in another layer of shared ownership and mutability
will allow updating all `TextFragment`s during repaint-only incremental
layout by simply updating the box tree styles of the original text
parents.
This adds a new set of borrows when accessing text styles, but also
makes it so that during box tree block construction
`InlineFormattingContext`s are created lazily and now
`InlineFormattingContextBuilder::finish` consumes the builder, making
the API make a bit more sense. This should also improve performance of
box tree block construction slightly.
Testing: This should not change observable behavior and thus is covered
by existing 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>
This makes it so that layout is no longer generic on the node type,
depending directly on `script`'s `ServoLayoutNode`. In addition to
greatly simplifying layout, this is necessary because incremental layout
needs to be able to create pseudo-element styles without having a handle
on the original `impl LayoutNode`. We feel this is a reasonable
tradeoff.
Testing: No functional changes, so covered by existing WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
`PositioningContext` held two vectors, one inside an `Option`, to
differentiate between the version used for a containing block for all
descendants (including `position: absolute` and `position: fixed`) or
only for `position: absolute` descendants. This distinction was really
hard to reason about and required a lot of bookkeeping about what kind
of `PositioningContext` a layout box's parent expected. In addition, it
led to a lot of mistakes.
This change simplifies things so that `PositioningContext` only holds a
single vector. When it comes time to lay out hoisted absolutely
positioned
fragments, the code then:
- lays out all of them (in the case of a `PositioningContext` for all
descendants), or
- only lays out the `position: absolute` descendants and preserves the
`position: fixed` descendants (in the case the `PositioningContext`
is only for `position: absolute`.), or
- lays out none of them if the `PositioningContext` was created for
box that did not establish a containing block for absolutes.
It's possible that this way of dealing with hoisted absolutes is a bit
less efficient, but, the number of these descendants is typically quite
small, so it should not be significant. In addition, this decreases the
size in memory of all `PositioningContexts` which are created in more
situations as time goes on.
Testing: There is a new WPT test with this change.
Fixes: #36696.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
As per
[w3.org/TR/filter-effects-1#FilterProperty](https://www.w3.org/TR/filter-effects-1/#FilterProperty),
`filter` shouldn't make the root element establish a containing block
for absolute and fixed positioned descendants. `will-change: filter` has
matching behavior.
This PR adds a check for if we are the root element before establishing
such a block.
To know if we are the root element, we look at the `FragmentFlags`
passed in. Previously for our function, these were dummy flags, always
constructed as empty. Thus, this PR also makes sure the correct
FragmentFlags are passed down the chain to the function
`establishes_containing_block_for_all_descendants`.
Testing:
- `/css/filter-effects/filtered-html-is-not-container.html` now passes
- `/css/css-will-change/will-change-fixedpos-cb-003.html` now passes
- Manual tests are working
Fixes: #35391
---------
Signed-off-by: haval0 <56519858+haval0@users.noreply.github.com>
Signed-off-by: Oriol Brufau <obrufau@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>
This is a followup to #36629, continuing to implement script-based
layout queries using the `Fragment`s attached to the `BoxTree`. In this
change, geometry queris (apart from parent offset) are calculated using
`Fragment`s hanging of the `BoxTree`.
In order to make this work, all `Fragment`s for inlines split by blocks,
need to be accessible in the `BoxTree`. This required some changes to
the way that box tree items were stored in DOM `BoxSlot`s. Now every
inline level item can have more than a single `BoxTree` item. These are
carefully collected by the `InlineFormattingContextBuilder` -- currently
a bit fragile, but with more documentation.
Testing: There are tests for these changes.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
https://drafts.csswg.org/css-align/#justify-block
Testing: Improves various WPT tests. `justify-self-auto-margins-2.html`
fails but I think the test is wrong.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
When doing any kind of query, up until now, containing block rectangles
were calculated by walking the `FragmentTree` until the node being
queried was found. In order to make possible answering queries without
walking the `FragmentTree`, `Fragment`s need to cache their cumulative
containing block rectangles.
This change adds a new `FragmentTree` pass (during construction) that
takes care of calculating and caching these values. The new cached value
is used during resolved style queries and also scrolling area queries
(with the idea that all queries will eventually use them).
In addition, extra `FragmentTree` walks used for cancelling animations
for elements no longer in the `FragmentTree` are integrated into this
new traversal.
Testing: Covered by existing WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-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>
