Bug 12063 - WebCore needs separate AnimationScheduler class for SMIL support
Summary: WebCore needs separate AnimationScheduler class for SMIL support
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 41761
  Show dependency treegraph
 
Reported: 2007-01-01 17:00 PST by Eric Seidel (no email)
Modified: 2012-05-04 07:44 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2007-01-01 17:00:05 PST
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).)
Comment 1 Eric Seidel (no email) 2007-01-01 17:04:37 PST
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.
Comment 2 Nikolas Zimmermann 2012-02-13 10:47:05 PST
This needs to be revisited to think about integration with CSS Animations.
Comment 3 Nikolas Zimmermann 2012-05-04 07:44:31 PDT
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.