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

On Wednesday 2010-01-06 16:25 -0800, David Singer wrote:
> 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?

This was just a restatement of (1) in a manner that is easier to
implement, since not all value types are easily subtracted.  So, in
other words, TFunc(Tcurrent) is the same as (VCurrent-Vstart)/(Vend
- Vstart), but is much easier to compute.

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

5. There was also what I called (2) below, which is basically a
variant of your (4), except jumping in to the timing function that
would apply based on current style rather than the timing function
that is the reverse of the currently running transition.


I think (5) is too jumpy (from trying to implement it; see quoted
material below).  I think (1/3) and (4) are acceptable visually,
though I've only actually implemented (1/3).  I haven't tried
implementing (2); I think it will still lead to transitions that
"look too slow" in some cases.

  * I actually did (1/3) both ways, but value subtraction (distance
    computation, actually) is a pain, although we have need much of
    that code for SMIL).

In terms of more technical disadvantages:

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

 (1/3) and (5) have the disadvantage that transitions on different
 timing functions, but the same duration/delay, when reversed, will
 return to the starting point at different times.

One other advantage of (1) (but not (3)) is that 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.)

-David

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

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Friday, 8 January 2010 00:51:00 UTC