Highlight selected text in input fields
Fixes#9993. This does not yet allow stylesheets to set the selection colors; instead it uses a hard-coded orange background and white foreground.
r? @pcwalton
<!-- 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/10176)
<!-- Reviewable:end -->
Generalize the style structs
This allows geckolib to pass gecko style structs and have the style system write to them directly, provided we implement all the traits.
<!-- 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/10155)
<!-- Reviewable:end -->
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.
Add WebRender integration to Servo.
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!
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9589)
<!-- Reviewable:end -->
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.
Fixing unused attributes warnings required updating serde_macros
which required updating to rustc 1.6.0-nightly (a2866e387 2015-11-30)
which required updating some other dependencies.
Instead of making a stacking context out of inline fragments parent
flow, make the inline fragment itself the stacking context. This fixes
positioning and rendering of these sort of fragments and prevents
over-layerization.
Fixes#7424.
Fixes#5812.
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
