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.
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
Instead of maintaining a dummy restyle damage field for text nodes, we can just
perform the necessary parent inheritance and is_changed adjustments on the fly
in ThreadSafeLayoutNode, simplifying the requirements on the style system.
MozReview-Commit-ID: DCqiCRLsLUF
A couple of changes here:
* Remove the option to unset with the dirty bit setters.
* Add an explicit API for setting text node style.
* Hoist has_changed handling into the restyle damage setter and text node style setter.
* Make set_style take a non-Option.
We don't need this for Gecko, and it's hard to implement in that case because
there's nowhere obvious to put it (we don't plan to create TSDs for non-dirty
nodes, and non-dirty nodes can have dirty children which require the
children_to_process atomic). There are various solutions here, but punting is
the easiest.
We'll need to rethink this if/when we need to do a bottom-up traversal for
Gecko.
It's not possible to implement a Ref::map equivalent method on AtomicRefCell
while having AtomicRefCell implemented on top of RwArc. We could potentially
reimplement AtomicRefCell to be more like RefCell and add a Ref::map equivalent
method, but I (and pcwalton) think we should try just cloning a few extra
Arcs at these callsites instead.
MozReview-Commit-ID: 6H8vAWguO3z
Add lots of Arc’s in style, and prepare for using DOMRefCell
<!-- Please describe your changes on the following line: -->
`DOMRefCell` usage is not there year because of thread-safety questions, but I have this much already that I’d like to land before it bitrots.
r? @emilio
---
<!-- 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 new tests because refactor
<!-- 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/13134)
<!-- Reviewable:end -->
a script query.
This will, rather unfortunately, mean that we might repaint two times if we've
deferred a paint, then get an out-of-band reflow. Still seemed better than not
suppressing paints at all.
Fixes#13131
This was the underlying cause of the restyle_hints_state.html failure.
It was uncovered only when fixing the HAS_EDGE_CHILD_SELECTOR flags because this
was the series of events happening.
* <script> starts executing.
* All the restyle hint processing takes place.
* <script> ends executing, gets appended to the body (I think this is also a bug).
* <body> receives children_changed notification, with an Append mutation.
* <body> had the HAS_EDGE_CHILD_SELECTOR flag, so due to its bogus value, it
restyled the whole tree after <body>, fixing any mishandling of restyle
hints.
The style candidate cache had regressed a few times (see #12534), and my
intuition is that being able to disable all style sharing with a single rule in
the page is really unfortunate.
This commit redesigns the style sharing cache in order to be a optimistic cache,
but then reject candidates if they match different sibling-affecting selectors
in the page, for example.
So far the numbers have improved, but not so much as I'd wanted (~10%/20% of
non-incremental restyling time in general). The current implementation is really
dumb though (we recompute and re-match a lot of stuff), so we should be able to
optimise it quite a bit.
I have different ideas for improving it (that may or may not work), apart of the
low-hanging fruit like don't re-matching candidates all the time but I have to
measure the real impact.
Also, I need to verify it against try.
In the Gecko case, this style source would be the style context. In the servo
case, it will be always the computed values.
We could optimise this further in the case of stylo (from three FFI calls to
one) if we use an API of the form CalcAndStore(node, new_cv). But that would
imply borrowing the data twice from Servo (we also have borrow_data_unchecked
fwiw, but...).
This is a rewrite for how style interfaces with its consumers in order to allow
different representations for an element snapshot.
This also changes the requirements of an element snapshot, requiring them to
only implement MatchAttr, instead of MatchAttrGeneric. This is important for
stylo since implementing MatchAttrGeneric is way more difficult for us given the
atom limitations. This also allows for more performant implementations in the
Gecko side of things.
