border box positions and transforms into account.
Clipping region computation now follows a simple process: (1) in the
parent's coordinate system, parents store appropriate clipping regions
into children; (2) each child moves its clipping region to its own
coordinate system if necessary.
Because clipping region computation is now based on stacking-relative
border box positions and the `transform_rect` method, it can handle
`position: relative` offsets and more types of transforms, such as
scaling.
Improves etsy.com.
Closes#13753.
Integrate stacking contexts into the display list
<!-- 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 _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Integrate stacking contexts into the display list by adding two new
entry types, PushStackingContext and PopStackingContext. This allows us
to eliminate the ugly offsets map that DisplayList used to contain
and seems to speed up display list construction. With this approach
we are able to also completely prune pseudo-stacking contexts from the
final display list and remove their (minimal) overhead from display
list traversal Traversing the display list is also a bit simpler now.
Additionally, this will allow easier editing of the DisplayList to
properly support scrolling roots. The push/pop entries can be
duplicated to clone complex StackingContext trees between layers.
<!-- 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/13682)
<!-- Reviewable:end -->
Integrate stacking contexts into the display list by adding two new
entry types, PushStackingContext and PopStackingContext. This allows us
to eliminate the ugly offsets map that DisplayList used to contain
and seems to speed up display list construction. With this approach
we are able to also completely prune pseudo-stacking contexts from the
final display list and remove their (minimal) overhead from display
list traversal Traversing the display list is also a bit simpler now.
Additionally, this will allow easier editing of the DisplayList to
properly support scrolling roots. The push/pop entries can be
duplicated to clone complex StackingContext trees between layers.
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.
Simplify the situations in which subpixels are accumulated, so that it
is only done for translation or identity transformation matrices. Also,
apply accumulated subpixels to more operations in PaintContext. This
fixes several pre-existing reftests and hopefully will eliminate
off-by-one errors in flaky reftests.
Fixes#10881.
Instead of simply rounding layer origins and discarding subpixel
offsets, accumulate them by transforming them into the space of the
next child stacking context. This is an attempt to eliminate subpixel
differences that are caused by different stacking context boundaries in
reference tests.
Currently these accumulated subpixels are only used for text
positioning, but the plan is that they can be used for all drawing in
the future.
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.
Replace character indices with UTF-8 byte offsets throughout the code dealing
with text shaping and breaking. This eliminates a lot of complexity when
converting from one to the other, and interoperates better with the rest of
the Rust ecosystem.
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.
This allows WebRender to correctly render complex clipping regions that
can be reduced to single rounded rectangles. WebRender still can't
render rounded rectangles with arbitrary intersections yet, but this
allows it to handle many more cases.
Closesservo/webrender#241.
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.
over the data as well.
WebRender doesn't need the data, as it acquires it separately.
About a 50%-100% improvement in display list building time on
browser.html.
Now that WebRender uses an Iframe display item, we do not need the Noop
item for the non-WebRender path. We can simply reuse the Iframe display
item. Also remove the layer_id member from the LayeredItem struct, as
it is unused.
`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.
WebRender is an experimental GPU accelerated rendering backend for Servo.
The WebRender backend can be specified by running Servo with the -w option (otherwise the default rendering backend will be used).
WebRender has many bugs, and missing features - but it is usable to browse most websites - please report any WebRender specific rendering bugs you encounter!
