This change reworks the layout DOM wrappers so that they are simpler and
easier to reason about. The main changes here:
**Combine layout wrappers into one interface:**
- `LayoutNode`/`ThreadSafeLayoutNode` is combined into `LayoutNode`:
The idea here is that `LayoutNode` is always thread-safe when used in
layout as long as no `unsafe` calls are used. These interfaces
only expose what is necessary for layout.
- `LayoutElement`/`ThreadSafeLayoutElement` is combined into
`LayoutElement`: See above.
**Expose two new interfaces to be used *only* with `stylo` and
`selectors`:**
`DangerousStyleNode` and `DangerousStyleElement`. `stylo`
and `selectors` have a different way of ensuring safety that is
incompatible with Servo's layout (access all of the DOM tree anywhere,
but ensure that writing only happens from a single-thread). These types
only implement things like `TElement`, `TNode` and are not intended to
be used by layout at all.
All traits and implementations are moved to files that are named after
the struct or trait inside them, in order to better understand what one
is looking at.
The main goals here are:
- Make it easier to reason about the safe use of the DOM APIs.
- Remove the interdependencies between the `stylo` and `selectors`
interface implementations and the layout interface. This helps
with the first point as well and makes it simpler to know where
a method is implemented.
- Reduce the amount of code.
- Make it possible to eliminate `TrustedNodeAddress` in the future.
- Document and bring the method naming up to modern Rust conventions.
This is a lot of code changes, but is very well tested by the WPT tests.
Unfortunately, it is difficult to make a change like this iteratively.
In addition, this new design comes with new documentation at
servo/book#225.
Testing: This should not change behavior so should be covered by
existing
WPT tests.
Signed-off-by: Martin Robinson <mrobinson@fastmail.fm>
`OutsideMarker::repair_style()` was setting `list_item_style` to the
style of the marker, not the style of the list item.
This patch sets it to `node.parent_style(context)` instead, and it fixes
`ServoThreadSafeLayoutNode::parent_style()` to take the pseudo-element
chain into account. This requires modifying a bunch of logic to pass the
`SharedStyleContext` around.
Testing: Adding a new test
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
This decreases the size of `TextFragment` by 66 bits and also allows
sharing empty metrics for text runs without fonts. Many `TextFragments`
should share the same font so these 66 bits should reflect reality even
though the `FontMetrics` is now stored on the heap.
Testing: This should not change behavior so is covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
We now follow the same approach as Blink: sequences of block-levels in
an inline formatting context get wrapped in an anonymous block, which is
treated as a line item. Inline ancestors are no longer split.
This means that inline elements will now generate a single inline box,
and the box tree makes more sense in general. This will help for
incremental layout.
This also means that block-level elements will now be properly affected
by effects like opacity of filters set on inline ancestors.
Recently, WebKit has done some similar work, but without the anonymous
blocks. We might also consider removing them in the future.
Google's explainer:
https://docs.google.com/document/d/15kgdIHhb9EVNup6Ir5NWwJxpzY5GH0ED7Ld3iMW3HlA/
Testing: Several tests are now passing
Fixes: #39813
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
As previously described in #41150 ,
`InlineFormattingContext::font_metrics` contains info that are easily
accessible via `FontRef`, and the `FontInstanceKey` is already cached in
the `FontContext`. Instead of keeping an index and obtaining these info
using the index, one should be able to obtain the same info via a
`FontRef`.
Testing: This should not change the expected behavior and the current
unit tests and WPT testcases should be sufficient.
Fixes: #41150
---------
Signed-off-by: minghuaw <michael.wu1107@gmail.com>
Use `ServoThreadSafeLayoutNode` in more places in layout rather than
`ServoLayoutNode`. The former is meant to be used during layout, but
layout 2020 was written against the latter. In general, this reduces the
amount of conversion to the thread-safe version in many places in
layout.
In addition, an unused iterator from the `script` crate
`ServoThreadSafeLayoutNodeChildrenIterator` is replaced with the child
iterator from `layout`. The `layout` version must be directly in
`script` now as it uses the dangerous variants of `next_sibling` and
`first_child`, which allow encapsulating the unsafe bits into one
module.
This will ultimately be useful for storing the layout data of
pseudo-element children of pseudo-elements properly.
Testing: This should not change any behavior and thus is covered by
existing tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This changes extend the incremental box tree construction for inline
boxes. Since an `InlineItem` can be split into multiple `InlineItem`s by
a block element, the reason such an inline item is marked as damaged may
simply be the removal of the block element or the need to reconstruct
its box tree. Therefore, under the current LayoutDamage design,
theoretically, even damaged inline items might still have some of their
splits reusable. However, based on the principle of simplicity and
effectiveness, this PR only considers reusing undamaged inline boxes.
Testing: This should not change observable behavior and is thus covered
by existing WPT tests.
Signed-off-by: sharpshooter_pt <ibluegalaxy_taoj@163.com>
Now that we are standardizing on the `_traits` crates becoming `_api`
and exposing the API of the crate that they get their name from [^1],
`script_layout_interface` becomes `layout_api` as it exposes the API for
`layout` that is used by `script` This brings the crate in line with the
naming of the other ones in `shared`.
[^1]:
https://servo.zulipchat.com/#narrow/channel/263398-general/topic/Organizing.20*_traits.20crates/with/396893711
Testing: This should not change any behavior and thus is covered by
existing tests.
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>
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>
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>
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>
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>
