These are two different passes during layout, but previously they
shared a state object. While some of the members are the same, many are
different so we separate them out into two separate objects. We also
change the HashMaps of these state objects to use the FnvHashMap.
Add support for position:sticky
This leverages the position:sticky support in WebRender to bring basic
support for position:sticky in Servo. There are still some issues with
nested sticky flows as well as a few other corner cases. Tests are
imported from WPT and can be removed once we update to the latest
version.
<!-- 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: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- 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/18212)
<!-- Reviewable:end -->
This leverages the position:sticky support in WebRender to bring basic
support for position:sticky in Servo. There are still some issues with
nested sticky flows as well as a few other corner cases. Tests are
imported from WPT and can be removed once we update to the latest
version.
When reflowing a block format context during the inorder traversal,
propagate restyle damage manually to its children since they were
already reflowed.
Collect scroll roots during the collect_stacking_context phase instead
of during display list construction. This will be useful in order to
collect containing block scroll roots as well as to give scroll roots
sequential ids in the future. This change also pulls stacking context
children out of the StackingContext struct itself, which should reduce
very slightly the memory used by the finished display list. This also
simplifies the DisplayListBuilder because it no longer has to maintain
a stack of ScrollRootIds and StackingContextIds and can instead just
rely on the program stack.
It turns out that it's problematic to embed ThreadLocalStyleContext within
LayoutContext, because parameterizing the former on TElement (which we do
in the next patch) infects all the traversal stuff with the trait parameters,
which we don't really want.
In general, it probably makes sense to use separate scoped TLS types for
the separate DOM and Flow tree passes, so we can add a different ScopedTLS
type for the Flow pass if we ever need it.
We also reorder the |scope| and |shared| parameters in parallel.rs, because
it aligns more with the order in style/parallel.rs. I did this when I was
adding a TLS parameter to all these functions, which I realized we don't need
for now.
This allows us to get rid of a bunch of lifetimes and simplify a lot of code. It
also lets us get rid of that nasty lifetime transmute, which is awesome.
The situation with thread-local contexts is still suboptimal, but we fix that in
subsequent patches.
This makes the API used to build display lists quite a bit simpler and
reduces the amount of auxiliary data structures that need to be passed
around. It is also important preparation work for separating scrolling
areas from stacking contexts.
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.
Simplify the way that stacking contexts are collected. Instead of
passing the StackingContextId down the tree, pass the parent
StackingContext itself. This will allow future patches to get more
information about the parent stacking context (such as location).
Also remove the return value of collect_stacking_contexts, which was
unused.
Separating out `REPOSITION` from `REPAINT` allows us to compute
stacking-context-relative positions without rebuilding the display list.
This saves a lot of time when responding to script-to-layout queries.
We don't really need two levels of abstraction for every element in the
DisplayList. This simplifies the complexity of the data structure in
preparation for providing documentation and properly handling scrolling
roots.
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.
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.
I forgot to do this along with the parallel case. Ideally I'd merge this patch
into that one, but then I'd need to rebase it over the LayoutContext patch,
which would be a pain.
