to-animation and animateTransform

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=""&gt;

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

<animateTransform attributeName="transform"
type="rotate" to="90" dur="2s" fill="freeze"/>



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=""&gt;

<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"/>



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 NullPointerExceptions.

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.


4 thoughts on “to-animation and animateTransform

  1. 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)


  2. 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.




  3. 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s