Confirmed users, Bureaucrats and Sysops emeriti
969
edits
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>[[ | 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, [[ | 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 ([[ | 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 | ||
[[ | [[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 |