SMIL:Timing Model

Overview

Following is an overview of the timing model suggested as part of a 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.

The parts in more detail

nsSMILAnimationController

This is the animation controller as discussed. It is responsible for the global animation timer.

This separates the actual refreshing from the timing model (as recommended by 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". 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 SMIL 2.0. I'm not pretending to understand of even to have read the SMIL 2.0 spec, but Schimtz describes a similar class so I think this interface would allow us to later support SMIL 2.0 time containers (not required by SVG).

The getNextChange() is something to be suspicious of. This seems like an obvious optimisation to me. If for example a document doesn't contain any animations, they are all inactive or the document fragment is paused then it should be possible to inform the animation controller of this so it can suspend the animation timer. Likewise, if no changes are likely to occur, and no events need to be generated for another 60 seconds, it should be possible to suspend the timer.

If, during that time, however an event arose or something like that, the requestUpdate method on the animation controller would be called so that if the timer was suspended it would 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 <animate> element is added via the DOM).

In order to be able to call requestUpdate(), 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 sampleAt.

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 refer to elements in other document fragments (and therefore potentially other namespaces) as syncbases, event bases and repeat bases. The SMIL Animation spec simply says that the element must be part of the host document (and the definition of host document is just a document containing animation elements).

This is also the object called by the root <svg> element of a document fragment to implement nsIDOMSVGSVGElement methods such as pauseAnimations, unpauseAnimations, animationsPaused, getCurrentTime, setCurrentTime. wallclockToDocumentTime() 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.

nsISMILTimeClient

This is the interface between the timing model and the 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, <animateMotion> could possibly be modelled as one nsSMILTimedElement with three time clients corresponding to the x, y, and transform 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).

nsSMILTimedElement

These elements contain the timing information associated with an animation element (e.g. an <animate>).

Again, there would definitely be an nsISMILTimedElement interface.

nsSMILTimeVal

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 wear of clearing out the list of accumulated intervals.

I suppose 64-bit integers will be faster than floats on a 64-bit processor but I don't know how they compare on a 32-bit processor.

nsSMILTimeValueSpecification

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.

Wallclock and syncbase dependencies may already be able to be treated quite similarly and I suggest possible event dependencies too. Rather than complicate this class with event listening and registering, we could define an nsSMILEventBase object that behaves like an nsSMILTimedElement for the purposes of time dependencies. This event base object would handle locating the target element, registering and listening for the event and the notifying the registered dependents.

nsSMILInterval

As mentioned, at a later stage it will probably be necessary to determine how to filter out some historical intervals. The SMIL Animation specification (3.6.8) doesn't give a lot of room to move here however.

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.

nsSMILInstanceTime

This class is as proposed by Schmitz.