Paced animation of complex types

Paced animation turns out to be tricky for some types. Translation, scale, and rotation in particular are tricky because the pacing must take place independently for each component of the transformation.

SVG 1.1 section 19.2.14:

If calcMode has the value paced, then a total “distance” for each component of the transformation is calculated (e.g., for a translate operation, a total distance is calculated for both tx and ty) consisting of the sum of the absolute values of the differences between each pair of values, and the animation runs to produce a constant distance movement for each individual component.

Consider this test graphic:

This example shows an example of paced rotation where the rotation angle and rotation center are animated with an <animateTransform> element.

The expected result is that the animation of bottom smiley is a combination of the ‘paced rotation’ and ‘paced movement’. That is, the rotation is paced and so is the movement.

Batik provides an example of this behaviour. Opera 9.62 Linux maintains a paced rotation but not paced movement.

The correct behaviour proves more difficult to implement and requires architectural changes to our model. It’s perhaps for this reason that SVG 1.2 Tiny has simplified this area so that the components don’t need to be paced independently.

UPDATE: I’ve discussed this with several people from the SVG WG and elsewhere and there seems to be consensus that the behaviour defined in SVGT1.2 should be backported by implementers of SVG 1.1.

4 thoughts on “Paced animation of complex types

  1. I think, the distance definition in SVG 1.1 for animateTransform did never fit to the
    requirements of calcMode paced (here especially to interpolate between the provided
    values), therefore this was already nonsense in SVG1.1.
    In SVGT1.2 the problem with the requirement to interpolate between the values was
    solved right from the beginning, however in the first drafts where some strange formulas
    not resulting in a paced behaviour ;o)
    For example for rotate with a rotation center changing within the animation there is no
    meaningful distance definition resulting in paced change. An initial formula was
    completely nonsense, because it added angles to lengths ;o)
    Now this is reduced to something, that really works at least, if the rotation center remains
    constant.

    In general if the animated attribute or property does not represent a vector or a scalar,
    there is no useful formula for a distance and therefore no general meaningful behaviour
    for paced. Therefore for those more complex structures it is obviously useful, just to
    ignore calcMode paced, because it has no meaning.

    I insisted a longer time to fix this and with SVGT1.2 the problem is solved now. What
    has a meaning related to a paced animation is defined in a meaningful way. Other
    complex types should not be animated with calcMode paced. If an author thinks, that
    (s)he a meaningful application, it is possible to calculate keyTimes for this and use them
    together with calcMode linear to get the desired effect.

    Like

  2. Hi Olaf,

    Thanks again for your helpful feedback here and elsewhere. It has helped me a lot and will no doubt aid us in producing a more compliant implementation in Mozilla. I wish we could implement SVGT1.2 behaviour in this case but I think we will need to stick with SVG 1.1 for now.

    Thanks again!

    Brian

    Like

  3. Hmmm – for animateTransform of the type translate you get already a funny result for the timing, if you use
    what is mentioned in SVG1.1. I think, noone tried to implement this for translate, because everyone noticed
    already, that the euclidian distance is related to the definition of calcMode paced here and not the
    ‘Manhattan distance’.
    Simply because the things mentioned for animateTransform contradict with the definition of calcMode paced,
    there is no correct behaviour defined for SVG1.1. Either you implement the nonsense mentioned for
    paced animateTransform or you implement something useful following the definition of calcMode paced –
    what results in the same, as defined now in SVGT1.2 (accept maybe for rotate with an animated rotation
    center, what is still somehow arbitrary what to do with this).

    And for the other complex types not beeing a vector or scalar, one can simply implement calcMode linear
    instead of calcMode paced. This is equivalent to a simple distance function, for example defining all distances
    as 1, this is not more or less meaningful than any other formula ;o)

    And if there is not already an entry, one can ask the SVG WG to add an error to the proposed errata list for
    SVG1.1, they are currently working on this again, and this paced behaviour for animateTransform is certainly
    an error ;o)

    Like

  4. Hi Dr. Hoffmann,

    Thank you for this clarification. After discussing this with a few other folk we’ve decided to go with the SVGT1.2 behaviour for this as you recommend. Thanks again!

    Brian

    Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s