Re: SVG and getCurrentTime

Hi Brian,

Thank you for the detailled reply. Regarding Chrome's behavior, I've 
filed a bug.

Regarding Web Animations, here are some comments.

> This part is yet to be spec'ed but I *think* the arrangement we will 
> end up with may be something like this:
>
> * Each Document has a timeline (the 'document timeline').
>
> The document timeline is not seekable/pauseable. This is because 
> pausing the document timeline, for example, would cause all UI 
> transitions to stop playing which is generally not what you want.
I understand the problem, but I would rather have UI transitions not 
locked onto the document timeline. Having the ability to expose controls 
(as with a video) to control the document timeline would be very useful.

> Also, making it seekable prevents UAs from making assumptions about 
> what animations can be safely dropped.
Right in some cases. But I still think the use case is important enough 
to keep the ability to seek in the timeline. We can find ways to signal 
which animations can be dropped.

> In order to support animations that start before onload, we'll either 
> (a) make this some very early moment in the page load timeline, (b) 
> make it configurable, or (c) allow creating custom timelines.
I think what we had in Tiny 1.2 with timelineBegin is a good start. 
Options (b) or (c) seem too complex.

>
> * Each outermost <svg> element would have an SVG timeline. This SVG 
> timeline can be seeked/paused. The methods currently defined on 
> SVGSVGElement would drive this SVG timeline. The start time of the SVG 
> timeline would be configurable (e.g. timelineStart="onstart").
>
> Whether this timeline is conceptually bound to the document timeline 
> or not only really matters if you can configure when the document 
> timeline starts. In either case, there would be methods to convert 
> times from one timeline to another.
Correct me if I'm wrong. You're saying you'd have 2 timelines, 
independent (in the SMIL syncBehavior sense, i.e. pausing one will not 
pause the other one) and the timelineStart attribute will give the 
mapping of time 0 on one timeline onto the other?
So if the outermost <svg> element is the root document element, you'd 
have two different APIs: getDocumentTime(), getSVGTime(), setSVGTime() ? 
That would be confusing.

>
> * Animations generated by SVG would be bound to the SVG timeline and 
> could be paused/seeked independently (using their corresponding player).
>
> This gives you two levels of pause control (per SVG document fragment 
> or per root-level animation element) which is more than you currently 
> have.
I'm not sure that is what you want be default though. If some animations 
were authored together, you probably don't want to pause one without 
pausing the others.
>
> An alternative arrangement is to simply to represent each outer <svg> 
> element as a par group bound to the document timeline and map the 
> playback control methods to the par group's player. That would only 
> give you one level of pause control. I'm not sure how big a deal that 
> is but when we thought about this back in February we seemed to think 
> two levels of play control was a good idea.[4]
My first thought is, unless an animation is completely independent from 
the other animations in the document, I don't think it make sense to 
control it separately. Having two levels of play control is probably ok 
but relying on indication from the author.

> All in all, I think the current spec text is not great but I think the 
> expected behavior of getCurrentTime after calling pauseAnimations is 
> clear enough to file a bug report.
Done.

>
> This area should become clearer with Web Animations. If you have any 
> particular input about the above arrangement I outlined for SVG that 
> would be useful.
Hopefully, but we should make sure simple scenarios (one SVG document 
with one outermost <svg> element) stay simple. I think working on 
examples would help.

Regards,

Cyril

-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/

Received on Thursday, 11 July 2013 14:30:46 UTC