SMIL:Timing Model: Difference between revisions

= Overview =

Following is an overview of the timing model suggested as part of a [[SVGDev:Possible SMIL timing and animation model|Possible SMIL timing and animation model]]. Note that attributes are not shown, return values are often omitted, some interfaces have been omitted and many data types are not specified as the appropriate NSPR / Moz type.

http://brian.sol1.net/svg/designs/iteration-1/timing-model-1.png

= The parts in more detail =

This is the animation controller as discussed. It is responsible for the global (per-document) animation timer.  

This separates the actual refreshing from the timing model (as recommended by [http://www.ludicrum.org/plsWork/ Schmitz]). This would allow tuning of the frame rate on a per-document basis.

This class also provides some document-level control of animation. For example, "Stop all animations on this web page" could be implemented using such an object. There would also be nsISMILAnimationController so we could provide a consistent interface to the outside world but I haven't shown that here.

== nsISMILTimeContainer ==

This is a SMIL time container as described in [http://www.w3.org/TR/2005/REC-SMIL2-20050107/ SMIL 2.0]. I'm not pretending to understand or even to have read the SMIL 2.0 spec, but Schmitz describes a similar class so I think this interface would allow us to later support SMIL 2.0 time containers (not required by SVG).

If however, during the time when the animation timer is suspended, an event arises, the <tt>requestUpdate()</tt> method on the animation controller would be called so that timer could be started again. I expect most SVG documents will have no animation or a very short-lived animation and it is important to optimise these cases. (However, we must always create the animation controller etc. because we need to record the document start time in case later an <tt>&lt;animate&gt;</tt> element is added via the DOM).

In order to be able to call <tt>requestUpdate()</tt>, the nsISMILTimeContainer would probably need to keep a weak reference to its animation controller.

This interface will probably eventually inherit from nsISMILTimedElement in order to support SMIL 2.0 time containers but for now the only common method I can see us implementing is <tt>sampleAt()</tt>.

== nsSMILDocumentRoot ==

This is where animations are registered. There will be one of these objects per SVG document '''fragment'''. There could be more than one document fragment per compound document and while it would not be possible to target elements in a different SVG document fragment for animation (SVG specifically prohibits this), my understanding of the SMIL Animation specification is that it would be possible to use to elements in other document fragments (and therefore potentially other namespaces) as syncbases, event bases and repeat bases. The [http://www.w3.org/TR/2001/REC-smil-animation-20010904/#Timing-SyncbaseValueSyntax SMIL Animation spec] simply says that the element must be part of the host document (and the [http://www.w3.org/TR/2001/REC-smil-animation-20010904/#Introduction definition of a host document] is just a document containing animation elements).

This is also the object called by the root <tt>&lt;svg&gt;</tt> element of a document fragment to implement nsIDOMSVGSVGElement methods such as <tt>pauseAnimations</tt>, <tt>unpauseAnimations</tt>, <tt>animationsPaused</tt>, <tt>getCurrentTime</tt> and <tt>setCurrentTime</tt>. <tt>wallclockToDocumentTime()</tt> shouldn't really be part of the interface exposed by this object to, e.g. nsSVGSVGElements, as it's only used by timed elements using a wallclock time. This suggests two separate interfaces but for now it doesn't seem necessary to split them and probably one nsISMILDocumentRoot interface would do.

 

The remainder of the timing model is nearly entirely the same as Schmitz's proposal.

This is the interface between the timing model and the [[SVGDev:Animation Model|Animation Model]]. The multiplicity on the association is not really necessary but would allow, for example, one timing specification to target several attributes. For example, <tt>&lt;animateMotion&gt;</tt> could possibly be modelled as one nsSMILTimedElement with three time clients corresponding to the <tt>x</tt>, <tt>y</tt>, and <tt>transform</tt> attributes of the target element. Of course, we probably wouldn't want to do it this way (one transform matrix will probably do, depending on how other animations interact).

 

Again, there would definitely be an nsISMILTimedElement interface.

I was considering using 64-bit integers for time values. 32-bit integers would only give us a range of about 25 days (time values can be negative), and thinking long term this might not be enough. (Consider if someone decided to embed gecko in a display showing train timetables at a railway station with SVG used to display the clock. In that kind of situation you could have an animation that occurs once a month.) However, in order to support really long time spans like that we'd need to first find a way of clearing out the list of accumulated intervals.

This is where the parsing of individual begin and end times is performed. This could well be separated into an interface with several implementations corresponding to the different types of begin and end specifications (with a static factory method performing the parsing). Whether or not we do this will depend somewhat on how much code is common to all cases.

:The list of resolved times includes historical times defined relative to sync base elements, and so can grow over time if the sync base has many intervals. Implementations may filter the list of times as an optimization, so long as it does not affect the semantics defined herein.

This class is as proposed by Schmitz.