[1.2T-LC] animateTransform and underlying value

Hello SVG WG,

SMIL notes about the underlying value of an animation:
"The base value of a target attribute 'a' at time t is the value of 'a' to 
which animation is applied at time t."
and
"Animations can be defined to either override or add to the base value of 
an attribute. In this context, the base value may be the DOM value, or the
result of other animations that also target the same attribute. 
This more general concept of a base value is termed the underlying value."
and
"The underlying value u of a target attribute 'a' of an animation element 
at time t is the value of 'a' to which the animation effect is applied at 
time t."

In the table of SVGT1.2 '16.2.18 Attributes and properties that can be 
animated' it is noted for transform:
"Additive means that a transformation is post-multiplied to the base set of 
transformations."

and in 16.2.17 The 'animateTransform' element:
"When an animation is active, the effect of non-additive 'animateTransform'
(i.e. additive="replace") is to replace the given attribute's value with the
transformation defined by the 'animateTransform'. 
The effect of additive (i.e. additive="sum") is to post-multiply the
transformation matrix corresponding to the transformation defined 
by this 'animateTransform'."

The obvious conclusion is, that the underlying value for an additive
animateTransform is the base set of transformations at the time t 
and that the result of the animateTransform has to be post-multiplied
to the underlying value (which includes results from lower priority 
animations too).

Surprisingly 16.2.17 notes too (different from SVG 1.1):
"The underlying value of transform animations (see SMIL discussion of
animation function values) is the corresponding identity transformation
value."

This means especially, following this sentence new in SVGT1.2 compared 
with SVG1.1, that
a) the underlying value is time independent
b) the underlying value is always the same

Effectively this sentence prevents any visible effect from additive
animateTransform in conflict with the table of 16.2.18 and the additive 
sample of 16.2.17 and example: 19_01.svg of 16.2.3 and samples in the 
test suite like animate-elem-81.

My impression is, that it is neither intended that additive animateTransform 
show no difference to non-additive animateTransform nor that these conflicts
are intended. It looks more like a misunderstanding of the meaning of the 
SMIL definition of the 'underlying value', therefore I suggest simply to skip
in 16.2.17 the sentence 
"The underlying value of transform animations (see SMIL discussion of
animation function values) is the corresponding identity transformation
value."
and to explicitly note 'underlying value' in the table of 16.2.18:
"Additive means that a transformation is post-multiplied to the base set of
transformations representing the underlying value."
and in 16.2.17 too:
"The effect of additive (i.e. additive="sum") is to post-multiply the
transformation matrix corresponding to the transformation defined by
this 'animateTransform' to the the base set of transformations representing
the underlying value."


Because from-to, from-by and by animations are defined in SMIL already to 
be equivalent to the corresponding values animation (tests are already
available in the test suite), there remains no specific problem for those
notations for animateTransform too.

What remains is the problem with to-animateTransform, because this 
animation type is neither pure additive nor pure non-additive.
The following requirements for to-animations come from SMIL:
a) begin (additive) with the underlying value
b) end non-additive with the to value
c) specific formula defined in SMIL has to be used - 
    the formula defines a specific feature or behaviour or functionality, 
    not available with other combinations of animations in SMIL/SVG.
    The main functionality it typically a smooth change from the 
    underlying value to the value specified with to
d) specified attributes additive or accumulate have to be ignored

The following requirement comes from SVG animateTransform
e) animateTransform has to be post-multiplied to the underlying value

There is especially a conflict between c) and e).
There are different more or less useful and simple possibilities to
solve this conflict. 
1) If e) is skipped, this requires an animation of the complete transform
     matrix in general to meet c) - this might be not completely trivial but
     is possible. Mainly one has to express the underlying value as a matrix
     as well as the value of the to attribute and to interpolate between those
     two values as specified in SMIL to get the desired smooth change.
     Because to-animations behave always quite different from
     the other animation types, this does not create any inconsistency.
2) If c) is skipped, this results in the complete loss of the functionality of
     to-animations for animateTransform. If we accept this, possibilities  
     could be 
     2.1) to define to-animateTransfrom always to be a discrete animation,
     this avoids a direct conflict between c) and e) too, because SMIL
     defines the behaviour of discrete to animation not conflicting with e),
     therefore to-animateTransform has effectively the same functionality
     as a set animation, not directly available for transform currently.
     2.2) to define an arbitrary initial value as done by the current draft, 
     using effectively the identity transformation as initial value. 
     This provides no interesting functionality as well and means,
     that a) has to be skipped as well due to the problem with the
     underlying value as discussed above.
     2.3) to specify that to-animateTransform has no effect, to indicate,
     that not all requirements can be met. 
      

Side note:
In the table of 16.2.18 there are two notes about color conversion.
This looks like a missing word:
"Only additive if each value can be converted an RGB color."
->
"Only additive if each value can be converted (in)to an RGB color."?

Received on Wednesday, 1 October 2008 14:21:21 UTC