Re: animateTransform nad by-transformation

Daniel Holbert:
....
> In addition to the situation Dirk brought up, we get the following
> paradoxical but correct-according-to-the-spec behavior:
> a) The animation...
>     <animateTransform type="scale" by="0".../>
>     ...makes its target disappear.
> b) If you stack N copies of...
>     <animateTransform type="scale" by="1" fill="freeze" .../>
>    ...all targeting the same element, the final frozen result will be at
> scale=1 (as opposed to scale=N+1 or scale=N).
>
> (In part (b), if we had N animations with |by="2"| instead of |by="1"|,
> we'd end up with a result at scale=2^N)
>
> Anyway, I agree with Dirk that the existing Opera & Firefox-nightly
> behavior isn't immediately intuitive, but it does appear spec-correct
> (based on the animateTransform-specific text) and it does make more
> sense after reviewing that chunk of spec.
>
> ~Daniel

Note, that you get similar surprising effects for the types skewX and
skewY, however you will only notice a major effect with specific values
or in precision tests:

For skewing
<g transform="skewX(45)">
<animateTransform type="skewX" by="45".../>
</g>
is quite different than
<g>
<animateTransform type="skewX" values="45;90".../>
</g>
(note the mad angle 90 degree for skewing ;o)
just because tan(a+b) is typically not the same as tan(a) + tan(b),
what corresponds to a wrong order of calculating the
animation effect function and doing the matrix multiplication.

Similar should happen for rotations with a changing rotation
center (with T the translation part, D the rotation part, 
a and b representing the corresponding values):
T(a)D(a)T(a)^-1T(b)D(b)T(b)^-1 is typically not the
same as T(a+b)D(a+b)T(a+b)^-1

For simple rotations around the same center and translations the
transformation effect is chosen in such a way, that such operations
commutate, therefore for them even a slightly wrong interpretation 
of the recommendations provide the right result as it does for
animations using the elements animate, animateColor or animateMotion. 
For most attributes and properties it does not matter, in which order
to compute additive and cumulative behaviour, therefore there is
a high risk, that it is done wrong, what can be only exposed with
such few types and tests, where it matters.

The situation is more problematic for to-animation for animateTransform,
because to-animations are neither exactly additive nor non-additive and
the intention for a continuous to-animation is to have a continuous 
change from the underlying value to the to-value.
There is an explict formula in SMIL how to get this, but this is problematic
for animateTransform with its postmultiplicative behaviour - what does
not directly apply to to-animations, because they are not really additive.
However there was no consensus to define for example, that one
has to apply the SMIL formula to the matrices related to the CTM and
the to-value, therefore the behaviour for animateTransform and 
for a to-animation is still undefined. 
Personally I would have needed this continuous behaviour already
several times for some practical applications similar to the new
 CSS3-transitions, therefore I think, this gap is more annoying 
than the minor unavoidable surprises with by-animations - but
it is not a perfect world ;o)


Olaf

Received on Tuesday, 6 April 2010 11:02:15 UTC