SMIL:Timing Model: Difference between revisions
m (Updated links) |
(Update broken links) |
||
(13 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
= | = Timing model = | ||
An overview of the classes that make up the timing model is shown below: | |||
http://brian.sol1.net/svg/designs/ | http://brian.sol1.net/svg/designs/current/timing-model.png | ||
= | == 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). | |||
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 <tt>GetNextChange</tt>. | |||
This | This optimisation would also imply some way of starting the timer again if, for | ||
example, an event arose. This could be handled by a <tt>RequestUpdate</tt> | |||
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 <tt><animate></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 | This interface will probably eventually inherit from nsISMILTimedElement in | ||
order to support SMIL 2.0 time containers but this is not required for SVG. | |||
== nsSMILTimedDocumentRoot == | |||
This is a concrete implementation of [[#nsISMILTimeContainer|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 | |||
[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). | |||
In | In addition to implementing [[#nsISMILTimeContainer|nsISMILTimeContainer]] this class also provides | ||
methods for resolving wallclock times and seeking for hyperlinks. | |||
This | 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. | |||
== | == nsSMILTimedElement == | ||
Contains the timing properties of an animation element such as | |||
<tt><animate></tt>. 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. | |||
== nsISMILTimeClient == | == nsISMILTimeClient == | ||
This is the interface between the timing model and the animation model. | This is the interface between the [[SMIL:Timing Model|timing model]] and the [[SMIL:Animation Model|animation model]]. Currently only one time client is supported per timed | ||
element. This may be extended in order to support <tt><animateMotion></tt> | |||
which may, for example 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. 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 <tt>x</tt> | |||
attribute and a higher-priority additive animation targeting the <tt>y</tt> | |||
attribute). | |||
== | == nsSMILTimeValueSpec == | ||
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|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. | |||
== nsSMILInterval == | |||
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. | |||
== nsSMILInstanceTime == | |||
Represents an instant in document simple time that may be used to construct | |||
a new interval. | |||
== | == nsSMILTimeValue == | ||
Simple time value data type. Times are expressed as a signed 64-bit integer | |||
representing milliseconds or the special values ''indefinite'' or | |||
''unresolved''. | |||
<!-- | |||
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. | |||
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. | |||
--> |
Latest revision as of 14:00, 20 March 2009
Timing model
An overview of the classes that make up the timing model is shown below:
nsISMILTimeContainer
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.
nsSMILTimedDocumentRoot
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.
nsSMILTimedElement
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.
nsISMILTimeClient
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).
nsSMILTimeValueSpec
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.
nsSMILInterval
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.
nsSMILInstanceTime
Represents an instant in document simple time that may be used to construct a new interval.
nsSMILTimeValue
Simple time value data type. Times are expressed as a signed 64-bit integer representing milliseconds or the special values indefinite or unresolved.