SMIL:Animation Model: Difference between revisions

killing SVGDev
m (SVGDev:Animation Model moved to SVG:Animation Model: killing SVGDev)
(killing SVGDev)
Line 22: Line 22:
<tt>nsSVGSVGElement</tt> checks if this member is NULL and if it is, it sets it
<tt>nsSVGSVGElement</tt> checks if this member is NULL and if it is, it sets it
with a new <tt>nsISMILAnimationController</tt> object. The controller object is
with a new <tt>nsISMILAnimationController</tt> object. The controller object is
required even for un-animated SVG in order to initialise the <tt>[[SVGDev:Timing Model#nsSMILTimedDocumentRoot|nsSMILTimedDocumentRoot]]</tt> with the appropriate start time for the
required even for un-animated SVG in order to initialise the <tt>[[SVG:Timing Model#nsSMILTimedDocumentRoot|nsSMILTimedDocumentRoot]]</tt> with the appropriate start time for the
document in case animation is later added via the DOM. (While this is strictly
document in case animation is later added via the DOM. (While this is strictly
how it should work I'm not sure how important it is. We could create the
how it should work I'm not sure how important it is. We could create the
Line 30: Line 30:
acceptable.)
acceptable.)


See also, [[SVGDev::AnimationController|roc's original description of the requirements for an animation controller]].
See also, [[SVG:Animation Controller|roc's original description of the requirements for an animation controller]].


== nsSMILAnimationRegistry ==
== nsSMILAnimationRegistry ==
Line 52: Line 52:
'''3. It allows the compositing to be controlled 'from above'.''' This is probably the most significant deviation from
'''3. It allows the compositing to be controlled 'from above'.''' This is probably the most significant deviation from
[http://www.ludicrum.org/plsWork/papers/BatikSMILsupport.htm Schmitz's design]. In his design the timing and animation model are very elegantly kept at arm's
[http://www.ludicrum.org/plsWork/papers/BatikSMILsupport.htm Schmitz's design]. In his design the timing and animation model are very elegantly kept at arm's
length through the time client interface ([[SVGDev:Timing Model#nsISMILTimeClient|nsISMILTimeClient]] in my implementation). So how does the compositor
length through the time client interface ([[SVG:Timing Model#nsISMILTimeClient|nsISMILTimeClient]] in my implementation). So how does the compositor
know when to perform compositing? Well, the composable objects hand their
know when to perform compositing? Well, the composable objects hand their
results 'up' to the compositor and it counts them until it figures it has enough
results 'up' to the compositor and it counts them until it figures it has enough
Line 62: Line 62:
The implementation I've produced here operates in the opposite direction. The
The implementation I've produced here operates in the opposite direction. The
composables simply store the sample parameters provided through the
composables simply store the sample parameters provided through the
[[SVGDev:Timing Model#nsISMILTimeClient|nsISMILTimeClient]] interface. These parameters include
[[SVG:Timing Model#nsISMILTimeClient|nsISMILTimeClient]] interface. These parameters include
information such as the simple time of the last sample. After all composables
information such as the simple time of the last sample. After all composables
have been sampled the registry is told to start compositing. The compositor then
have been sampled the registry is told to start compositing. The compositor then
Confirmed users, Bureaucrats and Sysops emeriti
969

edits