One issue that is not spelled out with regards to `<animateTransform>`

is its interaction with to-animation. to-animation produces a special kind of animation that interacts with its base value, however it is unclear just what this base value is in SVG 1.1.

Consider the following case (Case 1):

<svg xmlns="http://www.w3.org/2000/svg">

<path d="M-2 50h4v -90h4l -6 -10 -6 10h4z" fill="blue"

transform="rotate(-90)">

<animateTransform attributeName="transform"

type="rotate" to="90" dur="2s" fill="freeze"/>

</path>

</svg>

It’s pretty easy to work out what should happen here. The animation should interpolate from -90 to 90. The base value is that rotation transformation of -90 degrees.

Here’s the result in your browser:

But what happens if the underlying value is more complicated like so (Case 2):

<svg xmlns="http://www.w3.org/2000/svg">

<path d="M-2 50h4v -90h4l -6 -10 -6 10h4z" fill="blue"

transform="rotate(-90) translate(0 50) scale(2)">

<animateTransform attributeName="transform"

type="rotate" to="90" dur="2s" fill="freeze"/>

</path>

</svg>

What’s the base value now? Are you really supposed to pull apart the transform list and try to come up with something that will result in a rotation from -90

to 90 now?

Most implementations say no. Opera and Batik both behave as expected for Case 1. For Case 2, Opera just rotates from 0 to 90 which I believe is correct (there was some discussion of this on www-svg about an identity transform), whilst Batik 1.7 throws `NullPointerException`

s.

Here’s the result in your browser:

This is pretty confusing for web authors which is perhaps why in SVG1.2 Tiny they just made it undefined.

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)

LikeLike

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

LikeLike

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.

LikeLike