It seems that changeset 97ce9ed5b0
mistakenly changed the check that a cascade level to keep is *not* an
animation level to a check that it *is* an animation level.
To support visited styles, we match and cascade a separate set of styles any
time we notice that an element has a relevant link.
The visited rules and values are held in `ComputedStyle` alongside the
regular rules and values, which simplifies supporting various APIs like
`cascade_primary_and_pseudos` which expect easy access to previously matched
rules.
To simplify passing the additional values around, an additional reference to the
visited `ComputedValues` is placed inside the regular `ComputedValues`.
MozReview-Commit-ID: 2ebbjcfkfWf
In the case where we process an element which has SMIL animations in normal travesal
the SMIL styles must have been computed in animation-only restyles. So we
have only to pick the computed styles instead of recomputing it.
We add one FFI, Servo_GetProperties_Overriding_Animation, which calls
StrongRuleNode::get_properties_overriding_animations() to get a LonghandIdSet,
which may override animation properties running on compositor.
Now this method covers SMIL override rules, CSS animation / script
animation rules, and CSS transition rules so we should just use
"animation" in the generic sense.
I've commented on the ones that I think are the most tricky. Note that this code
is stress-tested in the style tests (tests/unit/style/rule_tree/bench.rs).
We can't assume all our siblings are alive because they may very well be in the
free list too.
This tempts to happen when the rule nodes are destroyed as part of the last GC,
the one that runs in the root destructor.
Also, properly put the next sibling back into the list when the rules are GCd.
RuleTreeDeclarationsIterator would yield &PropertyDeclaration
with the lifetime of the rule tree, but the reference would only
be valid as long as the iterator was holding the corresponding lock.
The lock would be released when the iterator’s `.next()` method
moves to the next rule tree node, or when the iterator is dropped.
Also change apply_declaration to not require a `Clone` iterator
(since closures unfortunately don’t implement `Clone`).
Instead have it take a callable that returns a fresh iterator.
This patch introduces infrastructure for the rule tree, and constructs it.
We don't use it yet, nor have good heuristics for GC'ing it, but this should not
happen anymore once we store the rule node reference in the node.
I haven't messed up with memory orders because I want to do a try run with it,
then mess with them.
Take down the ApplicableDeclarationsCache, use the rule tree for doing the cascade.
