Re: [1.2T-LC] 16.2.9 by 'identity' (ISSUE-2093, ACTION-2319)

Hello Brian,

according to my understanding of SMIL animation, the neutral
element for addition for transform scale is indeed 0,0 and not
1,1. This is because if you have a scaling A you get
A + (0,0) = (0,0) + A = A. Therefore (0,0) is the identity for addition.
The equation is not true, if you use (1,1) instead of (0,0), therefore
(1,1) is surely not the identity for addition.
There exist constructions with more than one neutral element
of addition in mathematics, but this fortunately does not appear
within SVG currently ;o)
What identity (element) means (especially in english) seems to be 
confusing here related to matrices. The relevant thing one has to 
look for, for which operation it results in an identity. For SMIL 
animation we have to care only about addition. 
A matrix is called an identity matrix or better unit matrix or in
German Einheitsmatrix, if it produces the identity for matrix
multiplication. For addition this is called the zero matrix.
http://en.wikipedia.org/wiki/Neutral_element

animateTransform does not animate matrices themselves,
currently not even the type matrix is animatable (unfortunately).
It animates numbers, from which later matrices are derived
with additional definitions. There is no relation between the
animation function and the rules, how to derive the matrix 
from the numbers.

SMIL animation interpolates between the given values with 
some kind of additive interpolation and does not care about 
the meaning or later appearance. 
This ensures, that at least the animations are continous, if the
first value is 0 (for cumulative and additive behaviour).

That for example a by-animateTransform always starts with
a zero scaling is not related to SMIL animation, this is only related
to a specific rule for animateTransform, that additive animations
(the corresponding matrices) have to be postmultiplied to the 
underlying value, or alternatively and more precisely, which matrix
corresponds to the scale type.
If we have the scale(0,0) this is according to SVG the zero matrix.
This could have been defined in a more useful way for scaling to
avoid different problems, but it is a little bit late now to adjust this.
For example if scale(a,b) would represent a matrix
matrix(exp(a) 0 0 exp(b) 0 0) this could have avoided the problem
for scale animations and the problem to have no inverse for
constrained transformations. However, then there is a need again
to have an additional operation to mirror an object.
The problem with the inverse happens too for skewX/Y if the 
tangens is infinity and there is a big difference too in animating 
the skewX/Y values or to animate the related matrices and
there is of course a big difference between the addition or
accumulation of the skewX/Y values or the postmultiplication
or accumulation of the transformations. Therefore for all these
animateTransform issues one first has to calculate the
complete animation function including cumulation. As a final
step one has to care, whether the animation is additive or
not. If it is additive, one has to postmultiply the resulting 
matrix of the animation effect to the underlying value.
This specific behaviour is already indicated be the element
name animateTransform. Therefore one does not have to 
care about the meaning of the animated attribute, 
because the animation effect is calculated independently.
I think, for implementors this ensures, that they can have
some generic SMIL module to calculate the animation function
for all animation issues together.
Only for the SVG animateTransform they have to calculate
the final presentation value/effect slightly different due to the
specific postmultipication rule.

There are only a few exceptions. 
One is implied by the calcMode paced. To achieve the conditions 
of this mode, one has to know something about the animated 
attribute or property to get a paced effect. The distance functions
depends on the animated attribute/property. This and for which 
attributes this is applicable is clarified now in SVGT1.2.
(This is not interesting for by, from-by, from-to and to animations
and for animations with not more than two values in the values
list).

The second is, that SVG defines, that additive animateTransform
has to be postmultiplied instead of added to the underlying value.
This is indicated already by the name of the element 
animateTransform. This has only influence on the final 
presentation value and how it is derived from the underlying 
value and the animation effect, but not on the other 
calculations of the animation function.
This causes a currently unsolved problem for continuous 
to-animateTransform, because it cannot be both the effect 
as described by SMIL, mainly a smooth change from the 
underlying value to the to-value, while it is postmultiplied.

Another minor (?) problem is a mixture of non interpolable
an interpolable values within the animation and for additive
animation including the underlying value (this can happen 
for example for SVG fill and stroke, which are very complex, 
maybe due to bad design of these attributes; some
functionalities should have been separated more carefully, 
but this is too late now). Obviously those animations cannot 
be continuous, if such a mixture appears.
I think, the animation program has to analyse first the
values and the underlying value to decide, whether the
calcMode is discrete or continuous (something like this is
already indicated within the definition of calcMode).
The open problem here is maybe, that animations can end
with interactive events, therefore the animation program
cannot know always, if the underlying value is something
usable for additive animations.

Olaf

Received on Thursday, 11 December 2008 11:12:05 UTC