Re: SVG and getCurrentTime

(2013/06/26 4:40), Cyril Concolato wrote:
> Hi all,
>
> During our previous F2F, I presented a JS SVG player behaving like a
> video player [1]. I mentionned that I had a problem with the way
> getCurrentTime() on the root SVG element was behaving, namely that calls
> to getCurrentTime() in Chrome would return different values over time
> when pauseAnimations() had been called. It was mentioned that it was
> probably a bug in Chrome and that it should work in Firefox. I've tested
> it [2] and indeed it works in FF. I wanted to file a bug on Chrome but
> found out that the spec is not really crystal clear on this.
>
> The spec says:
> "float getCurrentTime()
> Returns the current time in seconds relative to the start time for the
> current SVG document fragment. If getCurrentTime is called before the
> document timeline has begun (for example, by script running in a
> ‘script’ element before the document's SVGLoad event is dispatched),
> then 0 is returned.
> Returns
> The current time in seconds, or 0 if the document timeline has not yet
> begun. "
>
> Note that this does not mention from which clock the time comes from.

Yes, this spec text is messy. This whole section is messy. It would be 
more clear if it used the word 'clock' like all the related methods so 
it was obvious it was talking about the same concept.

Note that pause animations definitely does cause that clock to stop:

"Suspends (i.e., pauses) all currently running animations that are 
defined within the SVG document fragment corresponding to this ‘svg’ 
element, causing the animation clock corresponding to this document 
fragment to stand still until it is unpaused."[1]

(Also, the above description is *really* confusing since it refers to 
*this* 'svg' element despite the fact that in the context of animation, 
document fragments refer to the outermost <svg>.[2])

> setCurrentTime says:
> "Adjusts the clock for this SVG document fragment"
> Note the *the* clock, which seems to mean that there is only one clock
> for the document fragment.

Yes, this is spelled out in [2].

> getCurrentTime on animation elements says:
> "float getCurrentTime()
> Returns the current time in seconds relative to time zero for the given
> time container. "
> Here the notion of time container is introduced.

Yes, the use of different terminology here is sloppy.

> I think we all know and agree that there is only one time container in
> SVG 1.1 and that the clock of this container is the one used to get the
> currentTime from on the root element and on animation elements.

There is one per outermost <svg>. In an HTML document, you can have many 
time containers.

> But I couldn't find where this was clearly written.

It's in [2].

> This will probably be clarified with Web Animations too, but
> I don't know enough about it. Will the multiple time containers be
> locked/independent from each other? Will there be an API to pause the
> document time and all animations in the document?

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. Also, making it 
seekable prevents UAs from making assumptions about what animations can 
be safely dropped.

Exactly when this timeline starts is under consideration. The current WD 
says it starts on document load since that's what was spec'ed for 
CSS[3], but that's not what anyone implemented.

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.

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

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

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]


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.

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.

Thanks,

Brian

[1] 
http://www.w3.org/TR/SVG11/struct.html#__svg__SVGSVGElement__pauseAnimations

[2] http://www.w3.org/TR/SVG11/animate.html#RelationshipToSMILAnimation, 
paragraph 6 ("SMIL Animation requires that...").

[3] http://dev.w3.org/csswg/css-animations/#animations, "The start time 
of an animation is the latter of two moments: the time at which the 
style is resolved that specifies the animation, or the time the 
document's load event is fired."

[4] http://lists.w3.org/Archives/Public/public-fx/2013JanMar/0059.html

Received on Tuesday, 2 July 2013 04:23:08 UTC