Re: [web-anim] automatically discarding animations

(2012/08/07 16:13), François REMY wrote:
> |  I wonder if it's really necessary to be able to set this on a per-group
> |  basis. I think just specifying it on the effects timeline is sufficient.
>
> If I create a (sequenced|parallel) group of effects/animations, making
> it seekable disables any optimization on it, even if it's based on the
> 'effects' timeline (in my sense you don't need an effect timeline; the
> root timeline is not seekable it's the child who are).

How so? You can drop a sequenced or parallel group as soon as it becomes 
inactive.

I guess you're saying we couldn't drop any of the children of the group 
until the group itself finishes since you might want to seek the group? 
That's a fair point but I think it's ok since I don't imagine there will 
be additional long-running top-level groups created in the effects 
timeline. You might have complex effects that use nested sequence and 
parallel groups to coordinate the parts, but I imagine that the whole 
effect would normally be relatively short-lived and could be dropped as 
a whole before long.

> |  This important since some features like changing speed
> |  whilst maintaining position (changeSpeed), and reversing, rely on
> |  seeking. However, there is the caveat that once any child becomes
> |  inactive it is immediately detached from its parent.
>
> Those operations would not be allowed on non-seekable items. Authors who
> need seekability should just choose for a seekable timeline (ie: a
> seekable animation group).

I don't think that's a restriction we want to impose. If I have a lot of 
UI effects I want the container group to be not-seekable since I want to 
indicate that the effects can be dropped as soon as they are finished 
and because I never want to replay UI effects.

However, it's quite likely I might interactively want to reverse a UI 
effect in progress. A simple example is a cancelled transition. A more 
complex example is that I have an animation fired on mouse over. It is 
kept alive because it has a forwards fill mode and is therefore still 
active. On mouse out reverse() is called which also switches the fill 
mode (see the algorithm for changeSpeed). Therefore, when the reverse 
effect finishes there will be no fill mode and the animation is discarded.

Of course if we change reverse() to spawn a deep clone with negative 
speed and suitable iterationStart to achieve the seeking then maybe the 
restriction is ok, but I'm still a bit uncomfortable with it.

> |  (Currently I've called 'currentTime', 'animationTime', simply to match
> |  up with animationDuration. Let me know if you think currentTime is more
> |  clear.)
>
> It's just that 'currentTime' already exists on HTMLMediaElements. I'm
> not sure that a one-to-one mapping exists however.

Yes, I think we might stick with animationTime. It's one of the items on 
the agenda for tomorrow's meeting anyway: 
https://etherpad.mozilla.org/bfJdTefySR (along with a number of your 
other suggestions).

Thanks again François!

Brian

Received on Tuesday, 7 August 2012 08:01:53 UTC