Comments on: by-animation and scale transformations

By: Olaf

Olaf — Mon, 15 Dec 2008 09:47:41 +0000

The old SMIL animation recommendation is plurivalent in several points. For SMIL animation itself as defined
by SMIL this is in most cases no problem, but when animateTransform was introduced in SVG (this is not SMIL),
things got more complicated.
However, most plurivalences are already avoided in SMIL 2 and 3, therefore it is typically more useful to start
with SMIL 3 and to look into SMIL2 for SVGT1.2 if there are any incompatibilities and to look into the SMIL
animation recommendation for SVG1.1 for the same reason. In most case the more precise normative
definitions in SMIL 2 and 3 only clarify something, therefore they are not incompatible with the old SMIL
animation recommendation.

The authors point of view can be different for different authors, if someone needs a continuous cumulative
animation, it is certainly contraproductive to start with 1 instead of 0 either ;o)

By: Brian

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

Oh ok, now I understand what you mean by a neutral value. I agree that what you say makes sense from an implementation point of view. Indeed, this is the way I have implemented it.

But from an author’s point of view the paragraph I quoted from SMILANIM contradicts this. It refers to a delta from the underlying value which we both agree, in the absence of lower-priority animations, or other settings, is 1 for scale. So from an author’s point of view, by=”1″ should be a delta from 1.

So can we agree that the SMILANIM specification is contradictory at this point or at least ambiguous? It would be better if the quoted paragraph was replaced with the value=”0;by” additive=”sum” explanation.

By: Olaf

Olaf — Sat, 13 Dec 2008 13:22:15 +0000

The underlying values is always somehow defined, therefore there is no need to guess
one. Especially for animateTransform the underlying value is related to lower priority
animations and the complete value of the transform attribute. This can only be
assumed to be the identity transform, if there is neither a lower priority animation nor
a transform attribute. And this does not depend on the question, which type of animation
is currently used. Because this is a complex entity, additive animations have to be
postmultiplied and they are not somehow combined with only a notation of one
type like ‘transform’, ‘rotate’, ‘scale’, ‘skewX’, ‘skewY’. ‘matrix’ can be an underlying value
too, by the way. In SVGT1.2 even a constrained transformation can be an underlying value.

And by-animations do not start with the underlying value, they are only always additive,
what is a difference.

The by-animation itself is equivalent to a values animation.
With some pseudocode, if A is the value of the by attribute it is equivalent to
value=”0;A” additive=”sum”.
Furthermore, this animation type is only defined, if the attribute can be animated
additive at all (else it has no effect).
As without animation, the additive or cumulative effect of transformations can always
be tested with nested groups. Each group has only one transform type, respectively
animateTransform, the innermost element is the rendered object.
This nested group approach has to result always in the same effect as to postmultiply
something to a combination of animateTransforms and transform values.

Especially for the transform type scale one can have values as
A,B or only A, with A and B numbers.

If we have by=”7″ it is simply equivalent to
values=”0;7″ additive=”sum”. This is everything one has to check, to ensure, that
by-animations are implemented correctly.
If wie have by=”-2,3″ it is simply equivalent to
values=”0,0;-2,3″ additive=”sum” and this is the onyl thing, one has to check.
There is no need to check some arbitrary philosophical assumptions on one might be
nice under other circumstances or in another universe. This is simply, what is defined
as SMIL animation.
And to avoid further long philosophical discussions about the question, what the symbol
’0′ might be, in SMIL3 it is especially clarified, that it is the neutral element of addition
and nothing else. For a list of numbers this is related always to a list of zeros. For
colors it is related to #000 and not to ‘none’ or ‘transparent’ or whatever might be
funny or interesting under different circumstances.