Previously, the code that called this function was responsible for this.
Some code paths neglected to do it. This moves the damage removal to one
central location.
WebRender.
This happens asynchronously, just as it does in non-WebRender mode.
This functionality is a prerequisite for doing proper display-list-based
hit testing in WebRender, since it moves the scroll offsets into Servo
(and, specifically, into the script thread, enabling iframe event
forwarding) instead of keeping them private to WebRender.
Requires servo/webrender_traits#55 and servo/webrender#277.
Partially addresses #11108.
set to be scrolled.
This makes them establish stacking contexts, which is a CSS 2.1 spec
violation. However, we were already violating the spec here for
absolutely-positioned elements with `overflow: scroll`. It will probably
be easier to fix this spec violation once we either switch entirely to
WebRender or we have multiple layers per stacking context.
Closes#2742.
ComputedValues is now ServoComputedValues
This is the first part of #10185. More to follow. I have built this locally with both servo and geckolib without errors; let's see if it succeeds on all platforms as well.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10210)
<!-- Reviewable:end -->
This is the first part of #10185. More to follow. I have built this locally with both servo and geckolib without errors; let's see if it succeeds on all platforms as well.
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.
`memmove` was showing up high in the profile when concatenating and
shorting display lists. This change drastically reduces the `memmove`
cost in exchange for some minor additional allocation cost.
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.
