We only use whether the return value is IMPORTANT_RULES_CHANGED or not, so we
can just return true if an important rules was changed in the function.
Also, we can just return false in case of animation rules changes sine for
animation we can ensure there is no importan rules.
Because of these changes, replace_rule_node does not borrow |result| so that
we can drop a scope there.
If we add/remove important rules, we may need to update a list of all important
rules (in Gecko) which overrides animation properties. Therefore, we need to
set a flag if we update the primary rules which includes important ones.
If we have animations on this element, we update its effect properties, and
also send a task to update cascade results.
Calling get_properties_overriding_animations() might cases some impact
on performance because we need to walk the rule tree, so if possible, we could
just store this set into TNode to avoid finding the properties for both old
and new rules each time. This could be a future work if necessary.
I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
When an element has a display:none ancestor we don't traverse it during
restyle. However, at the end of restyling we expect the tree to be free
of dirty bits. We currently take special care to clear the regular
(non-animation) dirty bit on nodes in display:none subtrees in order to
preserve this invariant. This patch applies the same handling to the
animation-only dirty descendants bit.
While we're at it, we also eliminate the 'unknown' dom depth for the
bloom filter. Computing depth has negligible cost relative to the
amount of work we do setting up the bloom filter at a given depth.
Doing it once per traversal should be totally fine.
I originally separated the elimination of unknown dom depth from the
traversal changes, but I got bloom filter crashes on the intermediate
patch, presumably because I didn't properly fix the sequential traversal
for this case. Given that the final state is green, I just decided to
squash and move on.
The current mechanism requires threading a lot of this state through a bunch of
callsites that are several layers of abstraction above the code that actually
uses this vector (which is only compiled for servo). Putting it in
CurrentElementInfo gets it nicely out of the way.
MozReview-Commit-ID: 9PLBKcJreN0
This is necessary in order to make the computation of eager pseudos depend on
the primary ComputedValues, which we want to do for ::first-letter/::first-line.
This also fixes a bug where the behavior of EagerPseudoStyles::is_empty was reversed
in both the implementation and the callsite.
MozReview-Commit-ID: EXBxclyHWXu
This simplifies things by avoiding the computation of MatchResults when we
don't need them.
We continue to compute rule_nodes_changed, even though we don't use it
for the moment, since we will need it soon for various incremental restyle
optimizations.
MozReview-Commit-ID: 4qsUYaD5Bs2
All traversal processes are like this:
1. Traverse only elements that have this restyle hint (animation-only traversal)
RESTYLE_CSS_ANIMATIONS is stripped off from restyle hints of the elements
2. Traverse all dirty elements (normal traversal)
3. Create a SequentialTask if we have updated CSS Animations properties in
the normal traversal
4. Traverse elements that need to have updated animation style as a result of 3
(second animation-only traversal)
This is really part of the "recalc" rather than the "compute" work. But more to
the point, it lets us early-return on the style-sharing stuff (see the next patch).
We need to do something here to avoid a double-borrow when passing a mutable
StyleContext to match_element. After some discussion on IRC, we decided that
building the bloom filter for this case is probably worthwhile.
This way we'll be able to take different paths for the sequential and parallel
traversals in some concrete cases.
This is a preliminar patch to fix bug 1332525.
