Re: [web-anim] automatically discarding animations

(2012/08/06 17:15), François REMY wrote:
>> > As far as I can envision, I can see up to four different time sources
>> > being supported :
>> >
>> >     - RigidTimeSource implements TimeSource
>> >     - FluidTimeSouce implements TimeSource
>> >     - TimedItem implements TimeSource
>> >     - HTMLMediaElement (implements TimeSource)
>>
>> I think HTMLMediaElement and TimedItem should share the same behavior
>> with regards to inheriting time (since you want to be able to put a
>> <video> in a <par> or <seq>). In fact, I think all time sources should
>> inherit time from their parent. Root level time sources (the effects
>> and content timelines) get their time from the OS.
>
> Okay so, you mean that if I want a custom time source I should just
> create an animation group and use its built-in time source (which
> inherits time from the root time source) and
> seek/timeDrift/playbackRate-related methods and properties to have it
> work as if I had a custom timeline, right? This is an interesting,
> unified approach.
>
> This would lead us into a model where :
>
> - The default TimeSource (RootAnimationGroup) inherits time from the OS
> time, is not seekable.

Sort of. At the very root, is some OS-based monotonically increasing 
time source and that is not seekable. However, beyond that, every time 
source is potentially seekable. In the model I'm proposing, that 
OS-based time source has two children: the content timeline and the 
effects timeline.

The content timeline is seekable. The effects timeline is not, but 
that's just an arbitrary restriction we've imposed on it for performance 
reasons.

> - Every other timesource inherits time from its parent by default
> (currentTime=Range(parent.currentTime+timeDrift)*playBackrate;
> currentTime=min(currentTime, animationDuration);
> iterationTime=(currentTime mod iterationDuration);).

Yes, more or less. It's a bit more complex than that, but all those kind 
of formulae are already in the spec. See section 6.7 onwards.

(Currently I've called 'currentTime', 'animationTime', simply to match 
up with animationDuration. Let me know if you think currentTime is more 
clear.)

> - Animations groups can either have "isSeekable" set to true or false
> (set on creation only, readonly after). If "isSeekable" is true, we can
> rewind the animation group (timeDrift and playbackRate are read-write).
> If it's set to false, an attempt to modify timeDrift/playbackRate/other
> throws an exception. By default, timeDrift is equal to the time the
> parent time source had when the animation started.

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. 
That is, the effects timeline itself cannot be seeked. Children of it 
can however. 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.

Unfortunately, the ability to seek items in the effects timeline means 
that when an animation has a forwards fill, an implementations can't 
simply optimise it down to a single value, since it's still seekable. 
That's something we might need to revisit. We could make those 
animations non-seekable and, for example, make reverse() spawn a new 
animation to produce the reverse effect (that's how the reverse function 
I removed yesterday worked :).

> - An HTMLMediaElement is a time source; by default (if not specified in
> the markup) the media elements inherits their time from the document,
> but have isSeekable set to true; this is why we can pause them. If child
> animations are added to an HTMLMediaElement, its seekable timesource
> becomes the root time for those animations; any rewind in the video
> timeline affects its child animations.

Yes, that's what I'm thinking too (but minus the isSeekable part since 
I'm suggesting everything is seekable except the effects timeline).

Sounds like we're thinking similar things here. Thanks for your help.

Best regards,

Brian

Received on Tuesday, 7 August 2012 01:43:42 UTC