Comments on: Paced animation of complex types

By: Brian

Brian — Sat, 20 Dec 2008 03:59:34 +0000

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

By: Olaf

Olaf — Mon, 15 Dec 2008 10:11:40 +0000

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)

By: Brian

Brian — Sun, 14 Dec 2008 19:54:38 +0000

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

By: Olaf

Olaf — Sat, 13 Dec 2008 12:24:42 +0000

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.