Comments on: to-animation and animateTransform

By: Olaf

Olaf — Mon, 15 Dec 2008 09:57:54 +0000

Sure, there are always some limitations.
If nothing is changed, it still fits to the intented behaviour of SMIL to have a smoth change.
But for animateTransform, because it is just jammed together with SMIL animation without a careful design
and structure, one cannot expect, that everything is perfectly meaningful ;o)
I think, it would be a quite complex thing to design a collection of exception rules to cover all arbitrary cases,
what could be useful for authors.
Currently I do not know any viewer beeing able to get to-animations completely right even without the
complications of animateTransform. Therefore it would be to much to expect solutions for all specific cases
of animateTransform, what is not thought through very well at all.

By: Brian

Brian — Sun, 14 Dec 2008 19:35:43 +0000

Hi Olaf,

Thanks for your comment. What you say makes sense to me. I have one question however, what about when the underlying transformation is “rotate(-720)” and you have a to-animation of “rotate(360)”? Intuitively, that should produce an animation that rotates 3 times. But if you just use matrix interpolation you will have an animation that doesn’t rotate at all.

Once you special case rotation, I think you can no longer treat the underlying value as just a matrix. I tried to implement this in terms of matrices and it didn’t work because of the rotation issue.

Thanks,

Brian

By: Olaf

Olaf — Sat, 13 Dec 2008 12:51:40 +0000

The problem is, we cannot (always) have both, the functionality provided by SMIL to get a
smooth change from the underlying value to the to-value and to have the specific
rule from SVG to postmultiply the animation effect to the underlying value.

If we want to have the functionality of a to-animation as defined in SMIL – what is
obiously useful for authors, every other behaviour can be easily covered by other
animation types, but not that of a to-animation – we need to animate the matrix.
The underlying value can be represented by a matrix and the to-value can be
represented as a matrix. After this the interpolation between the matrices (!) can be
done as specified in SMIL, leading to a meaningful and useful behaviour.
(Note that unforunately the matrix type cannot be animated itself in SVG, but technically
there is no problem and the resulting effect is interesting – this can be simulated with
a frame based discrete animation for example with an animation of xlink:href of use
to exchange the displayed object, precaluated previously for each frame, with about
10-20 frames per second).
The requirement of SVG to postmultiply the animation effect causes a problem at least
for some situations. For most animations one can simply calculate the inverse of the
underlying value and after some recalculations one can get some formula, which
expresses the SMIL interpolation as a postmultiplied transformation.
However, because not for all possible underlying values the inverse exists, therefore this
does only work for most cases, not for all. And all this creates a lot of unneccessary
calulations, similar to the formalism introduced to realise a constrained transformation
in SVGT1.2 – what has the same problem with the possibly missing inverse.

Because there are no specific restrictions in SVG1.1, this is in general a defined
behaviour, as long as the inverse exists (and for other cases one can in general derive
the correct behaviour simply by ignoring the requirement to postmultiply ;o)