An overview of the classes that make up the timing model is shown below:
This is a SMIL time container as described in 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).
For example, if 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. This may be supported through a method such as GetNextChange.
This optimisation would also imply some way of starting the timer again if, for example, an event arose. This could be handled by a RequestUpdate method on this animation controller.
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 this is not required for SVG.
This is a concrete implementation of nsISMILTimeContainer. There is one such object 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 SMIL Animation spec simply says that the element must be part of the host document (and the definition of a host document is just a document containing animation elements).
In addition to implementing nsISMILTimeContainer this class also provides methods for resolving wallclock times and seeking for hyperlinks.
This class contains a pointer back to its parent animation registry to instruct it when to performing compositing and so the registry can update its observer.
Contains the timing properties of an animation element such as <animate>. This is perhaps the heart of the timing model as it is here that most the the rules for calculating new intervals, implementing fill modes, repeating, providing restart behaviour and so on are implemented.
Not shown in the diagram is an UnsetXXX method corresponding to each of the SetXXX methods. All attribute parsing and handling such as providing default values is performed within this class. This allows this logic to be shared between all animation elements.
This is the interface between the timing model and the animation model. Currently only one time client is supported per timed element. This may be extended in order to support <animateMotion> which may, for example be modelled as one nsSMILTimedElement with three time clients corresponding to the x, y, and transform attributes of the target element. Preferably though we could just implement this by changing one transformation matrix but I've yet to consider how this will effect the interaction with other animations (especially, for example, if there is another higher-priority non-additive animation targeting the x attribute and a higher-priority additive animation targeting the y attribute).
This is where the parsing of individual begin and end times is performed. Currently only offset times are parsed.
When we come to support other times we may decided to separate this class into an interface with several implementations corresponding to the different types of begin and end specifications (with a static factory method in the interface calling the appropriate concrete implementation). 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 possibly 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 then notifying the registered dependents.
This class is essentially a structure consisting of a begin and end time. It is used for representing the current interval and also for storing past intervals for the purpose of hyperlinking back in time.
Functionality will also be included for notifying instance times that depend on this interval (this is for syncbase timing) and recalculating.
Represents an instant in document simple time that may be used to construct a new interval.
Simple time value data type. Times are expressed as a signed 64-bit integer representing milliseconds or the special values indefinite or unresolved.