This will allow Servo to create ClipScrollNodes later during display
list construction, which will be necessary once rounded rectangles
are removed from the LocalClip structure. Instead of keeping track
of the ClipId of each ClipScrollNode, we keep track of its index in an
array of ClipScrollNodes. This will allow us to access them without a
hash lookup.
In order to properly handle CSS clipping, we need to keep track of what
the different kinds of clips that we have. On one hand, clipping due to
overflow rules should respect the containing block hierarchy, while CSS
clipping should respect the flow tree hierarchy. In order to represent
the complexity of items that are scrolled via one clip/scroll frame and
clipped by another we keep track of that status with a
ClipAndScrollInfo.
This allows us to have ensure_data() and clear_data() functions on the TElement
trait, instead of hacking around it adding methods in random traits.
This also allows us to do some further cleanup, which I'd rather do in a
followup.
Just use WebRender's ClipId directly. This will allow us to create and
use ReferenceFrames in the future, if we need to do that. It will also
make it easier to have Servo responsible for creating the root
scrolling area, which will allow removing some old hacks in the future.
While we're at it, we also eliminate the 'unknown' dom depth for the
bloom filter. Computing depth has negligible cost relative to the
amount of work we do setting up the bloom filter at a given depth.
Doing it once per traversal should be totally fine.
I originally separated the elimination of unknown dom depth from the
traversal changes, but I got bloom filter crashes on the intermediate
patch, presumably because I didn't properly fix the sequential traversal
for this case. Given that the final state is green, I just decided to
squash and move on.
This way we'll be able to take different paths for the sequential and parallel
traversals in some concrete cases.
This is a preliminar patch to fix bug 1332525.
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.
The primary idea of this patch is to ditch the rigid enum of Previous/Current
styles, and replace it with a series of indicators for the various types of
work that needs to be performed (expanding snapshots, rematching, recascading,
and damage processing). This loses us a little bit of sanity checking (since
the up-to-date-ness of our style is no longer baked into the type system), but
gives us a lot more flexibility that we'll need going forward (especially when
we separate matching from cascading). We also eliminate get_styling_mode in
favor of a method on the traversal.
This patch does a few other things as ridealongs:
* Temporarily eliminates the handling for transfering ownership of styles to the
frame. We'll need this again at some point, but for now it's causing too much
complexity for a half-implemented feature.
* Ditches TRestyleDamage, which is no longer necessary post-crate-merge, and is
a constant source of compilation failures from either needing to be imported
or being unnecessarily imported (which varies between gecko and servo).
* Expands Snapshots for the traversal root, which was missing before.
* Fixes up the skip_root stuff to avoid visiting the skipped root.
* Unifies parallel traversal and avoids spawning for a single work item.
* Adds an explicit pre_traverse step do any pre-processing and determine whether
we need to traverse at all.
MozReview-Commit-ID: IKhLAkAigXE
I realized that I fixed this issue incorrectly when the test failed before. Our design
document specifies that restyle hints must be expanded by the parent before traversing
children, so that we can properly apply LaterSiblings restyle hints. This includes
parents that do not themselves need processing (StylingMode::Traverse).
So we need to preprocess children even in the case where we don't restyle the parent.
On the flip side, we do in fact know whether a child needs processing before enqueuing
it, so we can skip the conservative visit I added before.
MozReview-Commit-ID: AEiRzdsN0h5
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.
