re-draft of the reversing positions...

I'm trying to collect all the options and opinions together to help us have a focused discussion and can reach an informed opinion...here's the latest roll-up.

* * * *

Given a situation where a transition runs from time 0 to Duration and is currently at time Tcurrent, and from values Vstart to Vend and is currently at Vcurrent, and has a delay D.  The user does something that interrupts the transition, so that it should 'reverse' before it's finished.  Running the full reverse transition may take much longer than the small amount of time the forward transition has run before it was interrupted.  What do we do?

I think we have these proposals:
1. [Value scaling] calculate scale-factor = (Vcurrent-Vstart)/(Vend - Vstart), and apply that to both the duration and the delay, and then run the entire reversal transition, with its delay, ease-in, ease-out etc. in that scaled duration and delay.  An easier way to calculate the scale-factor is to take the transition function, TFunc, which yields a value in the range 0 to 1, and use TFunc(Tcurrent).

2. [Time scaling].  Calculate scale-factor = Tcurrent/Duration, and apply that to both the duration and the delay, and then run the entire reversal transition, with its delay, ease-in, ease-out etc. in that scaled duration and delay.

3. [Follow back] Set yourself as if you were (Tduration - Tcurrent) into the reverse transition (i.e. as if it were running fully and had started sometime in the past), ignore delay, and ideally follow backwards down the forward function to the start.  This literally reverses. (I think this is what Dean wrote).

4. [Back down] Set the new time to be (Tduration - Tcurrent)-(starting delay) of the transition that would normally apply in this direction (i.e. as if it were running fully and had started sometime in the past).  Like [follow-back], but instead of trying to work the forward transition's function in reverse, use the transition that would normally apply, but leap into the middle of its timeline (delay included).

David has commented we want to avoid jumpiness, when we 'leap into the middle' of a timing function that would normally ease-in (or indeed 'leap out' of the middle of the forward function that would normally ease-out).  If we're trying to make it 'feel physical', then reversing an animation where there were eases at both ends of forward and reverse, should cause some sort of 'ease-around', but I see no simple way to specify that, and it seems over-complex for the problem. Ease-in/out currently, effectively, assume a zero starting velocity, which isn't the case when we interrupt.


Pros (+) and cons (-):

+[Value Scaling]
[David Baron] this is acceptable visually.
[David Baron] If we use the actual value-distance, it can be easily applied to shortening of transitions that aren't exact reversals (e.g., when a transition in progress reverses when its current position is closer to its new endpoint than its old endpoint was to its new endpoint, but the new endpoint is not the same as the original starting point).  (This is what's currently implementing in Gecko nightly builds, in fact.)

-[Value Scaling]
[David Baron] This the disadvantage that transitions on different timing functions, but the same duration/delay, when reversed, will return to the starting point at different times.

+[Time Scaling]
-[Time Scaling]
[David Baron] is concerned that this will 'look too slow' in some cases. The cases he's worried about are the cases where an 'ease-in' or 'ease-in-out' transition has made a good bit of time progress but only a very small amount of value progress, and is then reversed into something very-slow-moving.


+[Follow back]
[David Baron] This ought to be acceptable visually.  Apple suggested this and presumably some people there like it.

-[Follow back]
[David Baron] This has the disadvantage that it has a discontinuity between reversing a transition that's 99.9% complete and reversing one that's 100% complete.  This is also the disadvantage that it reverses the timing function that the author specified.


+[Back down]
-[Back down]
[David Baron] thinks this is too jumpy, from trying it.  He gives supporting material.
[David Baron] This the disadvantage that transitions on different timing functions, but the same duration/delay, when reversed, will return to the starting point at different times.



David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 15 January 2010 18:13:25 UTC