Optimize flat display lists
Flat display lists were a 2x regression on the spheres demo. This patch series fixes that.
See the individual commits for more details.
r? @mrobinson
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9843)
<!-- Reviewable:end -->
`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!
DisplayListSection, StackingLevel, and BackgroundAndBorderLevel all
represent pretty much the same thing, a particular section of the
display list. Instead of maintaining three enums which do the same
thing, just use DisplayListSection everywhere. It's a superset of the
other two and this change will make it easier to flatten the DisplayList
in the future for WebRender.
Correctly handle local sources for CSS3 fonts
Currently, servo panics for me when loading something like this:
```
@font-face {
font-family: "test family";
src: local(test font face);
}
```
That's due to a bug in `FontCacheTask`. `FontCacheTask` tries to get the value for the key
"test font face" from `self.web_families`, but previously initialized a value for the key "test family".
These two commits add an awkward test and fix the bug by not shadowing the variable `family_name`. Since the argument to `local()` should explicitly not be the name of a font family, the previous variable name was wrong and misleading anyways.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9149)
<!-- Reviewable:end -->
The argument to `local()` is not a font family, but the name of a
»single font face within a larger family« according to
http://www.w3.org/TR/css3-fonts/#src-desc.
The previous implementation of `FontCache::run` would panic if the argument to
`local()` would not be the name of a font family present in `self.web_families`.
That happened since `FontCacheTask` tried to use the argument to `local()` as a
key for `self.web_families`, although it previously correctly initialized a
value for the `family` field of the `AddWebFont` command.
