Bug 12063 – WebCore needs separate AnimationScheduler class for SMIL support

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Eric Seidel (no email)]

WebCore needs separate AnimationScheduler class for SMIL support

Some of this is talked about in bug 10931 (Animation Compositor support).  The current Animation support is inefficient (and broken) with regard to animation scheduling.  Right now one timer is created for every animation.  When any timer fires, all animations are re-applied and all animating elements are invalidated.  A better approach would be:

1.  Ideally only use a single animation timer (WebCore might already do this under the covers).
2.  add an AnimationScheduler::scheduleNextAnimation method which adjusts the timer to fire in time for the next animation.  (This method would be called all over the place -- any time an animation timing is changed, or an animation fires.)
3.  A single "AnimationScheduler::animationTimerFired" call, which builds the list of animations which are due to fire (currently part of this functionality is in SVGTimer::animationsByElement()).  This list should include *only* animations which are due to fire.  All SVGAnimate* classes will need to contain some sort of last fired state (at least an m_lastFiredTime) for aiding in the decision of if they are due to fire.
4.  Once a list of all due animations is built, this list should be converted into a list of Element/Attribute pairs that they effect.
5. An SVGDocumentExtensions (or AnimationController?) method should be called to look up all animations relating to each given Element/Attribute pair.  A separate method can be used to sort these animations by priority order.
6. For each Element effected, "AnimationCompositor::applyAnimations(SVGElement*, Vector<SVGAnimatedElement*>)" should be called with the sorted list of animations.
7.  AnimationCompositor::applyAnimations(SVGElement*, Vector<SVGAnimatedElement*>) should walk through each animation, calling "applyAnimationToValue" (or something like it) for each animation.  (Although it would be nice to walk backwards from the end of the list to the first "replace" animation and only apply from there forwards (as I suggested in bug 10931), that's not easy to do with inter-dependent properties (such as cx/fx in gradients).)

[Eric Seidel (no email)]

This ended up being a larger description of the needed animation system re-write.  I guess we'll still leave this bug to cover AnimationScheduler though.

[Nikolas Zimmermann]

This needs to be revisited to think about integration with CSS Animations.

[Nikolas Zimmermann]

Heh, this is long done in trunk, the SMILTimeContainer just works like Eric initially described. I think this bug can be closed, interaction with CSS Animation/Transition is tracked in bug 85059.