timing functions in reversed animations

This was discussed at the call today: http://lists.w3.org/Archives/Public/www-style/2011Mar/0744.html

What was intended in the original spec proposal, and what WebKit implements is actually pretty simple.

For any animation/transition, you calculate a "progress" based on (currentTime - startTime) / duration,
where startTime is the time the current iteration began, producing a value between 0 and 1. You use this
value directly when animating forwards. When you are in the reverse cycle, you use (1 - progress). This
value is then input into the style calculation.

Effectively this means a reverse phase is a mirror image of the forwards phase, as Simon said.

I think everything w.r.t keyframes becomes pretty obvious now, since you use the evaluated progress
to calculate where you are in the set of keyframes and forwards/reverse really makes no difference. You
never need to "flip" the timing function - it's the input progress that runs backwards in reverse.

e.g. consider you have keyframes at 20% and 40%, for an animation of duration 10s that iterates with reversal.

At time 3.5s, your overall iteration progress is 0.35. That is then evaluated to a inter-keyframe progress
of 0.75 between the 20% and 40% styles. Use the timing function from 20% to work out the interpolation
value given an input of 0.75, which is then fed into your style system to work out what the interpolated
style should be.

At time 16.5s, your overall iteration progress is 0.65. We're in the reverse cycle, so this becomes
(1 - 0.65) = 0.35. That is then evaluated to an inter-keyframe progress of 0.75 between the 20% and
40% styles.... etc, just like above.

If you're interested in the WebKit code, AnimationBase::fractionalTime is a nice place to start.

Received on Wednesday, 20 February 2013 18:09:40 UTC