animation-iteration-count property is a number instead of integer.
<!-- Please describe your changes on the following line: -->
This is a revised PR for #14732.
@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
<!-- Either: -->
- [X] There are tests for these changes
<!-- 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/14851)
<!-- Reviewable:end -->
transition is the same as the end value for a running transition per
CSS-TRANSITIONS § 3.
Besides being contrary to spec, the old behavior could cause a cascade
of CSS transitions incorrectly triggering themselves when calls to
`getComputedStyle()` were intermingled with them.
Improves performance of nytimes.com.
This commit itself only moves things around and adds an extra parameter to the
`apply_declarations` function to eventually handle #14079 correctly.
Probably needs a more granular API to query fonts, á la nsFontMetrics, but
that's trivial to do once this is landed.
Then we should make the font provider mandatory, and implement the missing stylo
bits.
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.
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...).
The previous behavior is plain wrong, since that array has always at least one
element, so we effectively couldn't specify anything else than "ease" in our
animations.
If we're restyling a page with animations and layout takes too long, we
might still have the expired animations from the last restyle, without these
being cleared out by layout on `tick_animations`.
Unfortunately it's hard (near to impossible?) to make a reduced test case for
this, since it heavily depends on the speed of the build and conditions that
only happen under heavy loads.
Mainly, it depends on how accurately the `TickAllAnimations` message is sent
from the constellation.
Thus, we can't just re-expire an animation, and we should re-check for it as a
previous animation.
Fixes#12171
Staticize CASCADE_PROPERTIES, (temporarily) fix stylo path for animations, and introduce the long-term path to follow
<!-- Please describe your changes on the following line: -->
---
<!-- 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
<!-- Either: -->
- [x] These changes do not require tests because refactoring + geckolib
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
@bholley: I was going to do this "the good way", but that involves quite a few properties, so I thought I'd rather unlock stylo before :)
r? @bholley
<!-- 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/11972)
<!-- Reviewable:end -->
This commit adds a need_index prop to the style system, and autogenerates
iterators, and a get_xxx_mod(i) function from a get_xxx_prop() and
get_xxx_at(index) functions.
This allows us to (finally!) take rid of the as_servo() hack. There are a few
unimplemented clones, but I'm just too lazy for that right now.
As a follow-up, we could move all the data living under a mutex in the
SharedLayoutContext only in order to create the local context to the same place.
This should increase animation performance when there are multiple animations in
one page that happen to be on different threads.
There's a bit of flickering when unpausing where the node has the original
state, but I'm not totally sure where it comes from, posibly from
PropertyAnimation returning None due to no styles changing?
There are a few shortcomings, for example:
* We don't do the same as other browsers when some properties are not specified
in some of the keyframes, though this is easy to work out (though a bit more
expensive in the sense that we should apply all the previous keyframes' style
instead of just the previous and the next.
* To trigger the initial animation, a restyle is necessary. Should be easy to
do an initial restyle off-hand or something like that, but for now this is
worked-around adding a :hover rule to the node.
Also, the animation is resetted when the node is hovered. That's a bug, but
is probably not so difficult to test.
* A few things, mainly animation-direction, are not supported yet, but
shouldn't be that hard to support.
Still a lot of work to do, but I think this approach might be ok.
There's some maths I've done wrong, but it DOES animate some things, though
they're only triggered past the first restyle, and we probably have some
duplications where the animations arrive to layout.
Anyway, got to go.
So this actually allows some more animations to be triggered. The bad part of
this is that they're actually triggered always when the style is recalculated,
so we're going to have at least some more state into the node, and the
constellation, which would have to keep track of the animations states.
