[SVGMobile12] 16.2.16 animateTransform

Hello,

I think, from SVG1.0/1.1 it is not
quite clear, how a scaling animateTransform
is applied correctly for many authors and
implementors.
As far as I have seen, the situation can get
worse with SVG1.2 mobile and SMIL2.0/2.1
for animateTransform in general.
Because animateTransform is just specified
in SVG, this is mainly a problem of SVG and
not of SMIL, to get the behaviour correct, useful 
and consistent in the viewers. 

In the SVGmobile1.2 draft, section 16.2.16 it is
added: 
"If from or to attributes are not specified, the 
underlying value (see SMIL discussion of animation 
function values) is the corresponding identity 
transformation value."

I tried to understand it but it is still a little
bit surprising what the use of this is.
The simplified meaning is, that under the
described conditions animateTransform cannot
be used with additive="sum".

If there is no underlying value explicitly defined, 
shouldn't the identity matrix be the underlying 
value for all animation types, not just for 
values-animations and by-animations
(they are the only animation types not using 
'from' or 'to' attributes)?
According to the SMIL recommendation we have
five types of animation:
1. values-animation (no from, no to, no by)
2. from-to-animation (no values, no by)
3. from-by-animation (no values,  no to)
4. by-animation (no values, no from, no to)
5. to-animation (no values, no from, no by)

No (from or to) is the same as (no from) and (no to).

4. and 5. have a definition of special behaviour
in SMIL. To get the correct behaviour of an
animateTransform as to-animation, viewers need
to implement something like an animation of
the matrix type, everything else is explained in detail
in SMIL. But 5. is the only type clearly excluded
by this rule, 2. and 3. seem to be excluded, but this is 
not the case, as we will see later.

The special rule from the animateTransform section
is for values-animations and by-animations, but
is it really the intention of the working draft to 
define something like this for values-animation and
by-animations?

This means in this example for a values-animation:

<g transform="translate(100,100) scale(0.5,0.5)">
<animateTransform 
   attributeName="transform" 
   attributeType="XML"
   type="scale" 
   values="1.5,1.5;4,-4"
   dur="5s"
   additive="sum" />
   <use xlink:href="#somecontent" />
</g>

for this simple animation without lower priority
animations the underlying value is the same as the 
base value "translate(100,100) scale(0.5,0.5)"
and it is overwritten by the identity matrix, e.g, scale(1,1).
Therefore the additive sum is ignored.
But animateTransform is described to support the
attribute additive in the 1.2 mobile draft (section
16.2.17) as in SVG1.0/1.1. 
This is a contradiction in the draft.
The visible effect for this values-animation is
the same as:

<g transform="translate(100,100) scale(0.5,0.5)">
<animateTransform 
   attributeName="transform" 
   attributeType="XML"
   type="scale" 
   values="1.5,1.5;4,-4"
   dur="5s" />
   <use xlink:href="#somecontent" />
</g>

or as:

<g transform="scale(1,1)">
<animateTransform 
   attributeName="transform" 
   attributeType="XML"
   type="scale" 
   values="1.5,1.5;4,-4"
   dur="5s" />
   <use xlink:href="#somecontent" />
</g>


But the problem is even bigger, because
SMIL2.0/2.1 defines from-to- and 
from-by-animations as shortcuts for 
values-animations.
This means, the special rule has to be
applied to from-to- and from-by-animations too.
For this case, the second example for animateTranform
is wrong too.

This rule is even more interesting for a by-animation,
because this is defined to be additive sum in general
by SMIL and not as additive replace.
This new rule means effectively, that by-animations 
should be ignored for animateTransform, because
it is not a solvable contradiction, SMIL says:

'Normative: A by animation with a by value vb is 
equivalent to the same animation with a values list 
with 2 values, 0 and vb, and additive="sum".
Any other specification of the additive attribute in a 
by animation is ignored.'

Even if we replace 0 carefully by the identity matrix, 
this will not solve the problem, because the underlying 
value is set to the identity matrix too and this is the 
same as additive="replace". 
And the SVG1.2mobile-draft refers to SMIL for details.
But it cannot be both, additive sum and additive replace ;o)

From the old specification the behaviour of a by-animation 
(not accumulative) was the same as an additive 
from-by-animation with the identity matrix as the
value of the from-attribute. Is it the intention of this 
part to say just this? 
But this from-value has nothing to do with the underlying 
value in SMIL.
If not, it would be easier to write the special rule as follows:
"The attribute value additive="sum" is not supported 
anymore for animateTransform in SVG1.2mobile.
by-animation is not supported anymore for
animateTransform in SVG1.2mobile. 
Note, that SMIL defines a special behaviour for to-animations."

If this is not the intention, it would be very helpful for authors
and developers, to clearify this in detail, else we will get 
different interpretations in different versions in every 
SVG-viewer. Authors will skip such type of animation, 
because it is not usable. 




Anyway, I think there is another question about the
correct behaviour of accumulate="sum" for animateTransform.
Is every iteration step post-multiplied to the previous
interation step or something else?
Especially it is not clear, how an accumulative 
by-animation for scale should work (maybe for other
animation types too).

Example:
<animateTransform 
   attributeName="transform" 
   type="scale" 
   by="1,1"
   accumulate="sum"
   repeatCount="2"
   begin="0s"
   dur="1s"
   fill="freeze"
/>

Is this the same visual effect as
(classical SVG1.0/1.1/SMILanimation style,
not implemented correct up to now in any
SVG viewer, as far as I have seen):

<animateTransform
   attributeName="transform"
   type="scale" 
   from="1,1"
   to="2,2"
   begin="0s"
   dur="1s"
   fill="freeze"
/>
 <animateTransform
   attributeName="transform"
   type="scale" 
   from="2,2"
   to="3,3"
   begin="1s"
   dur="1s"
   fill="freeze"
/>

or as (SMIL2.0/2.1, jump-style):
<animateTransform
   attributeName="transform"
   type="scale" 
   from="1,1"
   to="2,2"
   begin="0s"
   dur="1s"
   fill="freeze"
/>
 <animateTransform
   attributeName="transform"
   type="scale" 
   from="3,3"
   to="4,4"
   begin="1s"
   dur="1s"
   fill="freeze"
/>

or as (post-multiplicative style?):
<animateTransform
   attributeName="transform"
   type="scale" 
   from="1,1"
   to="2,2"
   begin="0s"
   dur="1s"
   fill="freeze"
/>
 <animateTransform
   attributeName="transform"
   type="scale" 
   from="2,2"
   to="4,4"
   begin="1s"
   dur="1s"
   fill="freeze"
/>

or as (SVG1.2 mobile? 
ignore-almost-everything-additive-style):
<animateTransform
   attributeName="transform"
   type="scale" 
   from="1,1"
   to="2,2"
   begin="0s"
   dur="1s"
   fill="freeze"
/>
 <animateTransform
   attributeName="transform"
   type="scale" 
   from="1,1"
   to="2,2"
   begin="1s"
   dur="1s"
   fill="freeze"
/>


The source of these difficulties is, that
scaling is a multiplicative operation 
(1 or the identity matrix is the neutral 
element of this operation and not 
0 as for other transformations 
like translation or rotation).
To get a useful result for animation,
it will be necessary to define in detail,
what are the changes compared to other
animations to get a useful and consistent
behaviour.
And if the desired behaviour should be 
different as defined by SMIL-animation, it 
is not useful to use the same values and 
to refer to SMIL for details.


Best wishes

Received on Sunday, 21 May 2006 14:42:39 UTC