Approach and credits
A much more thorough description of this model is available as a separate (PDF) report available at: http://brian.sol1.net/svg/report/report.pdf
I've gone through the SMIL Animation specification from which I developed my first design. Following this I went through Schimtz's proposal and revised my design significantly. Schmitz is one of the primary authors of SMIL 2.0 and SMIL Animation and has implemented the timing model several times so I'm very confident in his ideas.
Schmitz has confirmed that we may use his ideas in this way. So far the design follows Schmitz's proposal quite closely and I have clearly marked where it diverges.
Also, I have named several of the objects after those given in Schmitz's proposal so it should be fairly easy to see how this design conforms to and deviates from Schmitz's ideas.
Another source worth investigating for ideas may be X-Smiles.
An overview of the SMIL implementation is as follows:
The timing model is responsible for:
- begin and end times
- min, max
- repeat count, repeat duration
- fill mode
The animation model is responsible for:
When an SVG doc is created the outermost <svg> element creates the animation controller if it doesn't already exist in the current nsPresContext. This is performed even for SVG docs that don't contain animations so that the document begin time can be recorded in case animations are created later through script. This object is quite lightweight and is shared between SVG document fragments within a compound document.
When an animation element is created it requests an animation registry object which is created on demand. There is one registry per document fragment, i.e. one for each outermost <svg> element. As trees are re-arranged the owner of this registry has to be negotiated. I have several test cases showing this working when SVG fragments are combined, split and so forth.
This registry is used to register with the timing and animation model.
nsSVGAnimateElement is represented in the animation model by an nsSMILAnimationFunction and in the timing model by an nsSMILTimedElement. This approach, composition rather than inheritance should reduce the coupling between the SVG and SMIL modules and help us avoid MI nightmares.
All the parsing work including supplying default values is performed in the nsSMILAnimationFunction and nsSMILTimedElement. This simplifies nsSVGAnimateElement considerably and allows this functionality to be re-used by other animation elements such as <animateColor> and even in other host languages for SMIL.
View the details of the:
UML and XPCOM
A quick note about how the UML notation maps to XPCOM concepts. In the diagrams the filled diamond (composition), indicates exclusive ownership, i.e. the owned class's lifetime depends solely on its owner. In XPCOM terms this means the owner is the only object holding a (prolonged) owning reference to it. Other elements may have weak references to this element however.
The hollow diamond (aggregation) indicates shared ownership, i.e. in XPCOM several objects may have owning references to this object.
The line with an arrow (association) is the weakest relationship, in XPCOM this would probably be a weak reference or an owning reference held for a short time (same thing).
That said, there are likely to be many mistakes in this area as I haven't looked at ownership in any detail yet.
If you want to play with the diagrams just mail me for the original files. That's easier than putting up links to the XMI, SVG and ZUML (Poseidon) files. And while you're at it can I recommend Poseidon for UML from Gentleware. The community edition is free, very easy to use and exports SVG.