The style system never actually does anything with the document. This allows us
to remove a bunch of stubbing on the Gecko side and streamline some things on
the Servo side in future patches.
Don't promote all scrollable regions to stacking contexts
<!-- Please describe your changes on the following line: -->
Don't promote all scrollable regions to stacking contexts
Instead annotate all flows with their owning ScrollRoots. When
processing the display list items into a flattened display list, we add
PushScrollRoot and PopScrollRoot to signal when scrolling regions start
and end. It is possible for content from different scrolling regions to
intersect and when they do, the stack of scrolling regions is
duplicated. When these duplicated scrolling regions stacks reach
WebRender, it will scroll them in tandem.
The PushScrollRoot and PopScrollRoot items are currently represented as
StackingContexts in WebRender, but eventually these will be replaced
with special WebRender display items.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#13529 and #13298. (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14084)
<!-- Reviewable:end -->
Instead annotate all flows with their owning ScrollRoots. When
processing the display list items into a flattened display list, we add
PushScrollRoot and PopScrollRoot to signal when scrolling regions start
and end. It is possible for content from different scrolling regions to
intersect and when they do, the stack of scrolling regions is
duplicated. When these duplicated scrolling regions stacks reach
WebRender, it will scroll them in tandem.
The PushScrollRoot and PopScrollRoot items are currently represented as
StackingContexts in WebRender, but eventually these will be replaced
with special WebRender display items.
Fixes#13529.
Fixed#13298.
We also make sure that an element never has an ElementData with ElementDataStyles::Uninitialized,
and eagerly call prepare_for_styling whenever an ElementData is instantiated.
MozReview-Commit-ID: 9YP6eSmdMt0
Track overflow:scroll stacking contexts with ScrollRootId instead of StackingContextId
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because this PR should not change behavior.
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/13957)
<!-- Reviewable:end -->
This is a step in disassociating scrolling areas from stacking
contexts. Now scroll areas are defined by unique ids, which means that
in the future stacking context will be able to contain more than one.
Instead of maintaining a dummy restyle damage field for text nodes, we can just
perform the necessary parent inheritance and is_changed adjustments on the fly
in ThreadSafeLayoutNode, simplifying the requirements on the style system.
MozReview-Commit-ID: DCqiCRLsLUF
A couple of changes here:
* Remove the option to unset with the dirty bit setters.
* Add an explicit API for setting text node style.
* Hoist has_changed handling into the restyle damage setter and text node style setter.
* Make set_style take a non-Option.
The style candidate cache had regressed a few times (see #12534), and my
intuition is that being able to disable all style sharing with a single rule in
the page is really unfortunate.
This commit redesigns the style sharing cache in order to be a optimistic cache,
but then reject candidates if they match different sibling-affecting selectors
in the page, for example.
So far the numbers have improved, but not so much as I'd wanted (~10%/20% of
non-incremental restyling time in general). The current implementation is really
dumb though (we recompute and re-match a lot of stuff), so we should be able to
optimise it quite a bit.
I have different ideas for improving it (that may or may not work), apart of the
low-hanging fruit like don't re-matching candidates all the time but I have to
measure the real impact.
Also, I need to verify it against try.
Because this is a bottom-up traversal it can generates flows and throw them away. To prevent that, this cascades an internal `-servo-under-display-none` property and then checks that during flow construction. Fixes#1536.
speculation code.
The old code tried to do the speculation as a single bottom-up pass
after intrinsic inline-size calculation, which was unable to handle
cases like this:
<div>
<div style="float: left">Foo</div>
</div>
<div>
<div style="overflow: hidden">Bar</div>
</div>
No single bottom-up pass could possibly handle this case, because the
inline-size of the float flowing out of the "Foo" block could never make
it down to the "Bar" block, where it is needed for speculation.
On the pages I tried, this regresses layout performance by 1%-2%.
I first noticed this breaking some pages, like the Google SERPs, several
months ago.
some object needs to be repainted.
Reduces CPU usage when mousing over simple documents. (More complex
documents tend to trigger unnecessary reflow bugs and so still have high
CPU.)
Part of #9999.
bottom-up pass.
Right now, the only reason that overflow calculation works is that we
rely on script inducing extra reflows that are sent for display. This
was preventing #10021 from landing.
This change regresses layout performance by about 1% in my tests.
Fixes#7797 properly.
Instead of producing a tree of stacking contexts, display list
generation now produces a flat list of display items and a tree of
stacking contexts. This will eventually allow display list construction
to produce and modify WebRender vertex buffers directly, removing the
overhead of display list conversion. This change also moves
layerization of the display list to the paint thread, since it isn't
currently useful for WebRender.
To accomplish this, display list generation now takes three passes of
the flow tree:
1. Calculation of absolute positions.
2. Collection of a tree of stacking contexts.
3. Creation of a list of display items.
After collection of display items, they are sorted based upon the index
of their parent stacking contexts and their position in CSS 2.1
Appendeix E stacking order.
This is a big change, but it actually simplifies display list generation.
