SMIL:Animation Model

Overview

Following is an overview of the animation model suggested as part of a [[SVGDev::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. Underlined methods are static.

The parts in detail

nsSMILAnimationRegistry

This class acts as the single point of registry in both the animation and timing model. The appropriate nsSMILTimedElement and nsISMILComposable objects would be passed in along with perhaps the target attribute (for getAnimValue lookups as described next).

The getAnimValue method is to support the mode of interaction originally proposed by Alex (sorry no link). The main difference is that instead of having the compositor apply the new animation (presentation) value to the animated attribute--which breaks encapsulation a little, the animated attribute fetches its animated value from the animation registry during redraw (the animated value itself is still calculated in the regular way, i.e. as part of the traversal of the nsSMILTimedElements). This is a quick hashtable lookup and probably not a big performance penalty. This is the approach I used in my last prototype.

It doesn't matter which approach we use from the point of view of this model however. If we stick with applying the animation attribute from the compositor, we can simply remove the getAnimValue method from this class and the nsSMILCompositor.

nsSMILCompositor

I'm not quite sure how this part should work. There are probably many possibilities including:

1. All nsISMILComposable's provide their result to the compositor (composeResult()), and then the 'compositor' applies the necessary prioritisation and composition. This is the approach suggested by Schmitz (at least that's my understanding).
   
   
2. The timing model ensures that elements are sampled in correct priority order (from lowest to highest), and then when each nsISMILComposable goes to provide its result to the compositor it first requests the base value from the compositor (getBaseValue) which will return the cumulative result of animations on this attribute for the current sample (or the attribute base value if not animations have targetted it yet in this sample). The 'composable' object then performs addition (if it is an additive animation) and provides its result back to the composable object.
   
   The advantage of this second approach is that the compositor does not need to perform the actual addition, all this type-specific logic is concentrated in the composable object. Also, the compositor does not need to know if the composable object is additive.

Relative values and to animation could still be supported through the same mechanism by simply causing the compositor to remember the order in which it received results from its children. Probably I'm overlooking something however. For a start, I'm not sure how hard it will be to get the timing model to sample elements in priority order.

nsISMILComposable

This interface is discussed above. In both of the suggested modes of operation the data flows "up" from this object to the compositor. The calcResult method would only be used for later addition of the calculated values, such as when a relative measure needs to be updated.

nsSMILSimpleAnimElement

Base class for animation elements. The toValue may be redundant when inherited by nsSMILInterpolatingAnimElement. I'd like to see if it is possible to remove this inheritance relationship later and replace it with composition.

nsSMILInterpolatingAnimElement

Animation element object providing support for interpolation and addition.

nsSVGXXXElement

Schmitz stresses that:

It is important to be able to model timing as an extension of element behavior, rather than a completely separate model - this just makes it easier to code and manipulate.

Nevertheless, I would like to try and model this using composition instead in order to keep the content tree simple (and because it's always worth considering how we can avoid inheriting implementation).

nsISMILTimeScaler, nsSMILXXXScaler

It's probably not necessary to split this functionality up over so many object (it shouldn't be that complicated). The basic idea is to transform the simple time into something that will produce the correct result when linearly interpolated. Section 3.6.1 of the SMIL Animation Specification explains this much better.

nsISMILAnimValue, nsSMIL(CSS|SVG)XXXValue

This needs to be revisited. For now I've just based it on Schmitz's proposal but I'd like to see how we can integrate this with nsISVGValue rather than defining another data type abstraction interface. The only real requirement on this interface is that it allows the data types to be passed around transparently and that several static methods are available for defining a notion of distance and performing the addition and interpolation.