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.
It's a pointless abstraction that propagates the obsolete chan terminology,
swaps the order in which the sender and receiver are returned, and hides a
source of panics.
We do a few things-here:
* Hoist non-layout-dependent fields in SharedLayoutData and LocalLayoutData into style/.
* Hoist parts of css/matching.rs into style/.
* Hoist parts of layout/animation.rs into style/animation.rs.
* Remove the duplicated-but-slightly-different definition of OpaqueNode.
animations complete or are interrupted.
This adds a new pair of reader-writer locks. I measured the performance
of style recalculation on Wikipedia and the overhead of the locks was
not measurable.
Closes#7816.
There were two problems here:
(1) The animation state update function was only called when nodes were dirty or there were new animations.
(2) When all animations for a node expired, the entry from the hash table was not removed.
The result was that once an animation began, the compositor would be running as fast as it can forever.
Fixes#7721.
new styles are set.
Tying transitions to the DOM node avoids quadratic complexity when
updating them.
Finishing transitions instantly when styles are updated makes our
behavior more correct.
Transition events are not yet supported, and the only animatable
properties are `top`, `right`, `bottom`, and `left`. However, all other
features of transitions are supported. There are no automated tests at
present because I'm not sure how best to test it, but three manual tests
are included.
