Re: SVG and getCurrentTime

Hi Cyril,

Thanks for your follow-up and for filing the bug.

I think there are a couple of points I didn't explain properly and on 
which I think we agree.

(2013/07/11 23:30), Cyril Concolato wrote:
>> 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.

I think, as Shane said, it would be really helpful to flesh out the 
specific use case here.

If you want to take a whole lot of content and pause/seek it as a group 
you can:

* Wrap it in a top-level timing group and use its player, or
* Wrap it in an <svg> element and pause/seek the SVG timeline.

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

Yes, (a) seems likely. The trouble is it makes absolute time values for 
animations connected to the document timeline somewhat less useful.

We might be able to introduce (b) later by providing an API to delay 
animation start.

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

The document timeline can't be seeked/paused. Seeking/pausing an SVG 
timeline does not affect the document timeline.

The timelineStart attribute, if introduced, would simply determine the 
zero time of the SVG timeline. There would be methods to convert times 
expressed in one timeline to the other (see 'toTimelineTime' in the 
current spec).

If the outermost <svg> element is the root document element you would have:

   document.timeline.currentTime; // readonly, seconds since all
                                  // animations started

   document.documentElement.getCurrentTime(); // current play position
                                              // of SVG animation
                                              // elements (includes
                                              // effects of seeking,
                                              // and pausing)

Note that CSS Transitions and Animations will still be bound to the 
document timeline so calling document.documentElement.setCurrentTime() 
etc. will have no effect on them.

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

Yes, you can do both. If you have:

   <html>
     <svg id="a">
       <par id="group">
         <animate ... />
         <animate ... />
       </par>
       <animate id="animation">
     </svg>
   </html>

You can pause *both* 'group' and 'animation' using:

   document.getElementById("a").pauseAnimations();

But you can also pause just "group" using:

   document.getElementById("group").currentPlayer.paused = true;

(Or something like that; the API for this part is yet to be worked out.)

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

Yes, I think I didn't explain the two-levels of pause control properly. 
You can still pause everything at the outer-<svg> level. Then authors 
who wish to pause a component of an <svg> fragment can do so.

I think animations in <svg> fragments can sometimes act quite 
independently because they are can be triggered by UI events 
(begin="a.click" etc.) and therefore don't have any temporal 
relationship to other animations in the same fragment. As a result, they 
should probably be able to be paused/seeked independently.

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

Thanks!

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

Yes, I agree. I think nothing changes for one SVG document with one 
outermost <svg> element. There are additional interfaces available for 
advanced usage (e.g. pausing an individual animation), but the existing 
interfaces should continue to work as they currently do.

Regards,

Brian

Received on Tuesday, 16 July 2013 05:49:48 UTC