SMIL:Timing Model: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Updated links)
(Update broken links)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Overview =
= Timing model =


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.
An overview of the classes that make up the timing model is shown below:


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


= The parts in more detail =
== nsISMILTimeContainer ==


== nsSMILAnimationController ==
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).


This is the animation controller as discussed. It is responsible for the global animation timer.  
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 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 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.


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


== nsISMILTimeContainer ==
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 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).
This interface will probably eventually inherit from nsISMILTimedElement in
order to support SMIL 2.0 time containers but this is not required for SVG.


The <tt>getNextChange()</tt> 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.
== nsSMILTimedDocumentRoot ==


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 <tt>&lt;animate&gt;</tt> element is added via the DOM).
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 order to be able to call <tt>requestUpdate()</tt>, the nsISMILTimeContainer would probably need to keep a weak reference to its animation controller.
In addition to implementing [[#nsISMILTimeContainer|nsISMILTimeContainer]] this class also provides
methods for resolving wallclock times and seeking for hyperlinks.


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


== nsSMILDocumentRoot ==
== nsSMILTimedElement ==
 
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).
Contains the timing properties of an animation element such as
<tt>&lt;animate&gt;</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.


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 pauseAnimations<tt>, <tt>unpauseAnimations</tt>, <tt>animationsPaused</tt>, <tt>getCurrentTime</tt>, <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.
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
The remainder of the timing model is nearly entirely the same as Schmitz's proposal.
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. 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).
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>&lt;animateMotion&gt;</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).


== nsSMILTimedElement ==
== nsSMILTimeValueSpec ==


These elements contain the timing information associated with an animation element (e.g. an <tt>&lt;animate&gt;</tt>).
This is where the parsing of individual begin and end times is performed.
Currently only offset times are parsed.


Again, there would definitely be an nsISMILTimedElement interface.
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.  


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


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


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


== nsSMILTimeValueSpecification ==
Functionality will also be included for notifying instance times that depend on
this interval (this is for syncbase timing) and recalculating.


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


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.
Represents an instant in document simple time that may be used to construct
a new interval.


== nsSMILInterval ==
== nsSMILTimeValue ==


As mentioned, at a later stage it will probably be necessary to determine how to filter out some historical intervals. The [http://www.w3.org/TR/2001/REC-smil-animation-20010904/#Timing-BeginEnd-InstanceTimesLists SMIL Animation specification (3.6.8)] doesn't give a lot of room to  move here however.
Simple time value data type. Times are expressed as a signed 64-bit integer
representing milliseconds or the special values ''indefinite'' or
''unresolved''.


: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.
<!--
 
I was considering using 64-bit integers for time values. 32-bit integers would
== nsSMILInstanceTime ==
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 class is as proposed by Schmitz.
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:

timing-model.png

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.