Re: [css3-transitions] faster reversing of partially completed transitions

Given that I think we want "a reversed transition should take about the same amount of time to back out as it has run so far" I am not sure how to avoid "reversing jumpiness".

Could we get a summary of the proposals so far, and maybe their pros and cons?

Given a situation where a transition runs from time 0 to Duration and is currently at time T, and from values Vstart to Vend and is currently at Vcurrent, and has a delay D:

I think we have:
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.

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. [Shortening] "(1a) shorten the transition-duration (and any negative transition-delay) by the current value of the timing function of the transition in progress".  I can't work this one out;  if I am 8 seconds into a 10-second transition, and I expect to reverse, I subtract 8 from the duration and therefore back down in 2 seconds?

4. [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).

Are there other choices?  If not, can we summarize pros and cons?

On Dec 28, 2009, at 13:48 , L. David Baron wrote:

> On Monday 2009-12-28 13:31 -0600, Tab Atkins Jr. wrote:
>> On Mon, Dec 28, 2009 at 12:43 PM, L. David Baron <dbaron@dbaron.org> wrote:
>>>> (2) jump to the point in the timing function (at the specified
>>>>     transition-duration) for the reverse transition that would have
>>>>     the element at its current position (and thus ignore
>>>>     transition-delay entirely)
>>> 
>>> I tried implementing this, and it also looked horrible (due to
>>> unexpected jumpiness).
>> 
>> I'm curious about this.  Can you describe the jumpiness?  It doesn't
>> seem like anything should jump at all; is it that perhaps the element
>> changes velocity (not counting the reversal itself) in a possibly
>> discontinuous manner?  That is, with a transition that is ease-in both
>> ways, if you reversed it near the beginning of the transition it would
>> change from transitioning quickly (the start of an ease-in transition)
>> to transitioning slowly in reverse (the end of an ease-in transition).
> 
> Yes, it was just unexpected velocity changes: in particular, quick
> starts to movement for transitions that are 'ease-in-out' or
> 'ease-in' seem unexpected.  (Try, for example, mousing in and out on
> http://dbaron.org/css/test/2009/transitions/transition-timing-functions .)
> 
> Perhaps it's not that horrible, though.
> 
> In any case, demo builds with the code this way are at:
> https://build.mozilla.org/tryserver-builds/dbaron@mozilla.com-try-9d113f7acb59/
> (The Mac build isn't quite done yet, but should be there shortly.)
> Please do NOT use this as your main Firefox build; it will never
> auto-update so you'll be stuck with a random nightly.
> 
> For the record, this build consists of the source in:
> http://hg.mozilla.org/mozilla-central/file/699d0367eccf
> Plus these two patches:
> http://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/c44094e6c49c/transitions-division-crash
> (a patch that the next patch happened to be written on top of)
> http://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/fa6b2c782a68/transition-no-compute-distance
> (the patch that actually implements the behavior in question).
> 
> -David
> 
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 7 January 2010 00:25:39 UTC