Confirm
166
edits
Changes
Replaced proposed timing and animation model with new SMIL model page
These pages contain a proposed [[SVGDev:Timing Model|Timing Model]] and [[SVGDev:Animation Model|Animation Model]] as implemented at [http://brian.sol1.net/svg/ http://brian.sol1.net/svg/].
= Approach and credits =
This design is '''heavily''' influenced by [http://www.ludicrum.org/plsWork/ Patrick L. Schmitz's]
'''[http://www.ludicrum.org/plsWork/papers/BatikSMILsupport.htm proposal for supporting SMIL animation in Batik]'''.
I've gone through the [http://www.w3.org/TR/2001/REC-smil-animation-20010904/ SMIL Animation specification] from which I developed my first design. Following
this I went through Schimtz's proposal and revised my design
'''significantly'''. [http://www.ludicrum.org/plsWork/ 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.
[http://www.ludicrum.org/plsWork/ 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 [http://www.xsmiles.org/ X-Smiles].
= Overview =
An overview of the SMIL implementation is as follows:
http://brian.sol1.net/svg/designs/current/overview.png
The design is broken up into two main parts: the [[SVGDev:Timing Model|timing
model]] and the [[SVGDev:Animation Model|animation model]] as well as some
supporting infrastructure.
The [[SVGDev:Timing Model|timing model]] is responsible for:
* begin and end times
* duration
* min, max
* repeat count, repeat duration
* fill mode
* restart
The [[SVGDev:Animation Model|animation model]] is responsible for:
* from/to/by/values
* accumulate
* additive
* calcMode
* keytimes
* keysplines
=== Basic flow ===
When an SVG doc is created the outermost <tt><svg></tt> element creates
the animation controller if it doesn't already exist in the current
[http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresContext.h 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 <tt><svg></tt> 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 [[SVGDev:Animation Model|animation
model]] by an [[SVGDev:Animation Model#nsSMILAnimationFunction|]] and in the
[[SVGDev:Timing Model|timing model]] by an [[SVGDev:Timing
Model#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
[[SVGDev:Animation Model#nsSMILAnimationFunction|]] and [[SVGDev:Timing
Model#nsSMILTimedElement|]]. This simplifies nsSVGAnimateElement considerably
and allows this functionality to be re-used by other animation elements such as
<tt><animateColor></tt> and even in other host languages for SMIL.
View the details of the:
* [[SVGDev:Animation Model|Animation model]], and
* [[SVGDev:Timing Model|Timing model]].
= 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 [mailto:birtles@gmail.com 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
[http://www.gentleware.com/index.php?id=poseidon_for_uml Poseidon for UML] from
[http://www.gentleware.com Gentleware]. The
[http://www.gentleware.com/index.php?id=ce community edition] is free, very
easy to use and exports SVG.
= Approach and credits =
This design is '''heavily''' influenced by [http://www.ludicrum.org/plsWork/ Patrick L. Schmitz's]
'''[http://www.ludicrum.org/plsWork/papers/BatikSMILsupport.htm proposal for supporting SMIL animation in Batik]'''.
I've gone through the [http://www.w3.org/TR/2001/REC-smil-animation-20010904/ SMIL Animation specification] from which I developed my first design. Following
this I went through Schimtz's proposal and revised my design
'''significantly'''. [http://www.ludicrum.org/plsWork/ 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.
[http://www.ludicrum.org/plsWork/ 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 [http://www.xsmiles.org/ X-Smiles].
= Overview =
An overview of the SMIL implementation is as follows:
http://brian.sol1.net/svg/designs/current/overview.png
The design is broken up into two main parts: the [[SVGDev:Timing Model|timing
model]] and the [[SVGDev:Animation Model|animation model]] as well as some
supporting infrastructure.
The [[SVGDev:Timing Model|timing model]] is responsible for:
* begin and end times
* duration
* min, max
* repeat count, repeat duration
* fill mode
* restart
The [[SVGDev:Animation Model|animation model]] is responsible for:
* from/to/by/values
* accumulate
* additive
* calcMode
* keytimes
* keysplines
=== Basic flow ===
When an SVG doc is created the outermost <tt><svg></tt> element creates
the animation controller if it doesn't already exist in the current
[http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresContext.h 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 <tt><svg></tt> 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 [[SVGDev:Animation Model|animation
model]] by an [[SVGDev:Animation Model#nsSMILAnimationFunction|]] and in the
[[SVGDev:Timing Model|timing model]] by an [[SVGDev:Timing
Model#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
[[SVGDev:Animation Model#nsSMILAnimationFunction|]] and [[SVGDev:Timing
Model#nsSMILTimedElement|]]. This simplifies nsSVGAnimateElement considerably
and allows this functionality to be re-used by other animation elements such as
<tt><animateColor></tt> and even in other host languages for SMIL.
View the details of the:
* [[SVGDev:Animation Model|Animation model]], and
* [[SVGDev:Timing Model|Timing model]].
= 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 [mailto:birtles@gmail.com 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
[http://www.gentleware.com/index.php?id=poseidon_for_uml Poseidon for UML] from
[http://www.gentleware.com Gentleware]. The
[http://www.gentleware.com/index.php?id=ce community edition] is free, very
easy to use and exports SVG.
