This is the strategy we'll need to take for attributes, and so this change
puts us in a position to handle attributes and state the same way.
This does mean that we stop taking care to track the situations where our
state has reverted to the original state, with no net change. I think that's
probably of negligible value though.
This flag is no longer necessary, because stacking contexts can now
create layers lazily for content that needs to be stacked above a
layer. This should reduce the number of layers on pages, hopefully
reducing overdraw.
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.
This should make it somewhat easier to experiment with alternative
representations in the future. To reduce churn, this commit leaves the String
field public, though.
Also, this will allow us to use the default String type to represent the IDL
USVString type, which explicitly forbids unpaired surrogates, ans as such is
a better match to the Rust String type.
Mix stacking contexts into the positioned content list
Sometimes positioned content needs to be layered on top of stacking
contexts. The layer synthesis code can do this, but the current design
prevents it because stacking contexts are stored in a separate struct
member. In order to preserve tree order, mix stacking contexts into the
positioned content list, by adding a new StackingContextClass
DisplayItem. Such items do not have a base DisplayItem.
In some ways this simplifies the code, because we no longer have to
have a separate code path in the StackingContextLayerCreator.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8266)
<!-- Reviewable:end -->
Sometimes positioned content needs to be layered on top of stacking
contexts. The layer synthesis code can do this, but the current design
prevents it because stacking contexts are stored in a separate struct
member. In order to preserve tree order, mix stacking contexts into the
positioned content list, by adding a new StackingContextClass
DisplayItem. Such items do not have a base DisplayItem.
In some ways this simplifies the code, because we no longer have to
have a separate code path in the StackingContextLayerCreator.
Fixes#7779.
Fixes#7983.
Fixes#8122.
Fixes#8310.
Fix several bugs causing the page to reflow on every mouse move event
After all these changes are applied, Hacker News and GitHub only repaint and reflow nodes that actually have hover styles applied when the mouse moves over them.
r? @mbrubeck
cc @bholley
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8299)
<!-- Reviewable:end -->
add get_raw_layout_value (HTMLInputElementHelpers)
This resolves#8107
Previously the index of the insetion point for a password input was
calculated using the scrambled string based on the edit point in the
raw string. That could lead to a wrong position of the caret. This
commit changes this behavior to calculate the insertion point using
the raw string.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8265)
<!-- Reviewable:end -->
This resolves#8107
Previously the index of the insetion point for a password input was
calculated using the scrambled string based on the edit point in the
raw string. That could lead to a wrong position of the caret. This
commit changes this behavior to calculate the insertion point using
the raw string.
This is done in
`HTMLInputElementHelpers::get_insertion_point_index_for_layout`
and relies on a 1:1 mapping of the chars in the raw input to the
scrambled chars (currently bullets) in the password input.
Un-boxed ScriptReflow
As per #8238 I changed `layout_interface::Msg::Reflow` to store `ScriptReflow` rather than `Box<ScriptReflow>`
I ran the tests and believe everything passed but this is my first commit to the project so sorry if I messed up the protocol!
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8290)
<!-- Reviewable:end -->
This adds some overhead, but also provides the small performance benefit of
avoiding dirtying in the case where an event state is toggled an even
number of times between reflows.
The main benefit here though is that it sets us up to be smarter about
what we mark as dirty using restyle hints.
Fix start and end points for linear gradients with angle specified.
Previously, this was most noticeable with 45deg gradients, where the gradient would end too early, and the remainder was filled with a solid color.
(This also fixes gradients on webrender, which relies on the start and stop points being correct).
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8094)
<!-- Reviewable:end -->
