Re: timing functions in reversed animations

(2013/02/21 3:09), Dean Jackson wrote:
> 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.

That sounds like what we've specified for Web Animations as per this 
diagram:

 
https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/img/time-calculations.svg

i.e. the reversing (playback rate) is applied, then the direction, then 
the timing function.

The timing function is applied to a progress fraction in the way you 
mention (currently specified in 13.6 Calculating the transformed time, 
although section numbers will probably change a lot in the next few days).

> 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.

The operation of timing functions specified at keyframe-level operates 
as you suggest. That is, it takes place after the progress has been 
reversed.

If CSS wants to use a different approach for reversing then we would 
probably just define the mapping from CSS to Web Animations such that 
reversing generates a separate 'reverse' animation.

Best regards,

Brian

Received on Thursday, 21 February 2013 01:36:57 UTC