Re: [web-anim] automatically discarding animations

Hi François,

(2012/08/03 21:50), François REMY wrote:
> My intuition says that it should maybe be impossible to seek back and
> forward in time TimedItems unless it's explicitely stated on creation
> that it should be possible.

I think that's what the effects vs content timelines give us. Granted, 
you could move an item from one timeline to the other but no extra state 
is required to make that possible.

> BTW, I would remove the "timeStart" property. It's much easier to say
> that the document's time source is automatically started on load, except
>
>     - if its "autoplay" property is set to false before the page load
>     - if its "play" method is called before the page load (on document
> ready...)

If I understand correctly, the proposal is to remove 'onstart'. I 
*think* for the SVG and CSS bindings we probably want to be able to 
specify 'onstart' declaratively, but I'm ok with it not being in the 
Core API and having SVG and CSS implement this on top.

The reason I'm not certain we need 'onstart' is that many of the use 
cases it addresses, e.g. animating a spinner before the page loads, 
could now be addressed by the effects timeline (which starts immediately).

(By 'play' I assume you mean 'unpause'. I want to avoid adding a method 
just for kick-starting the timeline along with a yet-to-start state. 
Currently we simply re-use the pause behaviour.)

> If we provide both seekable and unseekable time sources to developers,
> I've the feeling we should continue to import attributes from the
> HTMLMediaElement interface. Interesting attributes includes:
>
>     - seekable : TimeRanges
>         The time ranges that the user is able to seek to, if any. Read
> only.
>
>     - seeking : Boolean
>         Indicates whether the time source is in the process of seeking
> to a new position. Read only.
>
>     - autoplay : Boolean
>         Indicates whether to start the time source as soon as it's
> ready. Defaults to true.

Oh, I see the reason for preferring autoplay. That makes sense. I'm not 
sure if we want to impose that on all animations though.

I'm not keen on the others but they may make sense once we think more 
carefully about video elements inside animation groups.

> As far as I can envision, I can see up to four different time sources
> being supported :
>
>     - RigidTimeSource implements TimeSource
>         initialTime
>             = 0 // once started with play() method
>
>         duration
>             = NaN // no limit
>
>         seekable
>             = TimeRanges[] // not seekable
>
>         autoplay
>             = true // auto-start by default
>
>         - animations going from active to
>             inactive are automatically discared
>
>         - we can get a global instance from
>             the document.timeSource property
>
>
>     - FluidTimeSouce implements TimeSource
>         initialTime
>             = 0 // once started with play() method
>
>         duration
>             = NaN // can be modified
>
>         seekable
>             = TimeRanges[<NegativeInfinity, PositiveInfinity>] // yes,
> anywhere; memory pressure can force to reduce the interval
>
>         autoplay
>             = true // auto-start by default
>
>         - animations going from active to inactive can
>             be discarded in case of memory pressure.
>
>         - the use of the seekable attribute allows to
>             know which time ranges are still supported
>             for seek operations.
>
>         - it's probably possible to allow authors to
>             specify a preferred seekDuration.
>
>
>     - TimedItem implements TimeSource
>
>         - see current specification.
>
>         - performs calculations based on
>             parent time source and timeDrift.
>
>         - used as time source for child items;
>             timeDrift allows to have the parent
>             time source to move on while keeping
>             children timed items at the same time
>             (paused).
>
>
>     - HTMLMediaElement (implements TimeSource)
>
>         - see the HTML specification for the
>             attributes default value and behavior.
>
> What do you think of this model?

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.

I'm not particularly keen on splitting off Rigid and Fluid time sources. 
It feels like generalising a solution when there are only two cases 
where we need it: the content and effects timelines. If we find 
additional applications we can split off an interface then but for now 
I'd like to avoid an explosion of interfaces.

For the content timeline we can just use a regular animation group and 
specify a few bits of exceptional behaviour (e.g. can't be re-parented). 
Likewise for the effects timeline (e.g. throws on seeking).

I want to come back to this later. I think we could do some renaming in 
TimedItem to align more closely but I don't think shoehorning 
HTMLMediaElement in is going to be a no-op. For a start, I think we 
might want to make media elements serve as animation groups.

What do you think?

Best regards,

Brian

Received on Monday, 6 August 2012 03:35:01 UTC