Comments on: Accumulation of transformations http://brian.sol1.net/svg News about my attempts to implement SVG Declarative (SMIL) Animation in Mozilla Wed, 01 Feb 2012 09:08:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Olaf http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/comment-page-1/#comment-32767 Olaf Sun, 04 Jan 2009 12:40:40 +0000 http://brian.sol1.net/svg/?page_id=49#comment-32767 SMIL does not care about animateTransform, therefore there is no reason to reinterprete formulas in SMIL, if this is not noted in SVG, where animateTransform is defined. And there is only the postmultiplication noted for additive behaviour. This means simply, that the SMIL formula for additive="sum" is not applicable, because it is overwritten by a special SVG rule. Cumulative behaviour is not overwritten, therefore there is no reason to believe, that '+' is not '+'. I noted already to the SVG WG, that if there is a need for a specific behaviour for animateTransform, this has to be defined completely in SVG. Except from to-animateTransform maybe, I think, there is no need to do this. Alternatively SMIL could adopt completely animateTransform and to care about it, but all this should have happend several years before. And there is no advantage in having yet another specific rule for cumulative behaviour for animateTransform ;o) SMIL does not care about animateTransform, therefore there is no reason to reinterprete
formulas in SMIL, if this is not noted in SVG, where animateTransform is defined. And there
is only the postmultiplication noted for additive behaviour. This means simply, that the SMIL
formula for additive=”sum” is not applicable, because it is overwritten by a special SVG rule.
Cumulative behaviour is not overwritten, therefore there is no reason to believe, that ‘+’ is not
‘+’.

I noted already to the SVG WG, that if there is a need for a specific behaviour for
animateTransform, this has to be defined completely in SVG. Except from to-animateTransform
maybe, I think, there is no need to do this.
Alternatively SMIL could adopt completely animateTransform and to care about it, but all this
should have happend several years before. And there is no advantage in having yet another
specific rule for cumulative behaviour for animateTransform ;o)

]]> By: Brian http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/comment-page-1/#comment-32730 Brian Sun, 21 Dec 2008 21:48:45 +0000 http://brian.sol1.net/svg/?page_id=49#comment-32730 And yet, SMILANIM 3.3.1 suggests that the types of addition are related when it says: <blockquote>[The cumulative attribute] is ignored if the target attribute value does not support addition</blockquote> And yet, SMILANIM 3.3.1 suggests that the types of addition are related when it says:

[The cumulative attribute] is ignored if the target attribute value does not support addition

]]> By: Brian http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/comment-page-1/#comment-32729 Brian Sun, 21 Dec 2008 21:19:05 +0000 http://brian.sol1.net/svg/?page_id=49#comment-32729 I think I finally understand this, so to clarify, in this formula for additive animation from SMIL3: <blockquote><code>F(t,u) = u + f<sub>f</sub>(t)</code></blockquote> the "+" operation is matrix post-multiplication for <code><animateTransform></code>. BUT, in the formula for cumulative animation in SMIL3: <blockquote><code>f<sub>i</sub>(t) = (f(d) * i) + f(t - (i*d))</code></blockquote> the "+" operation is just addition of the animation parameters. Likewise the multiplication operator. I think I finally understand this, so to clarify, in this formula for additive animation from SMIL3:

F(t,u) = u + ff(t)

the “+” operation is matrix post-multiplication for <animateTransform>. BUT, in the formula for cumulative animation in SMIL3:

fi(t) = (f(d) * i) + f(t - (i*d))

the “+” operation is just addition of the animation parameters. Likewise the multiplication operator.

]]> By: Brian http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/comment-page-1/#comment-32693 Brian Sun, 14 Dec 2008 19:50:53 +0000 http://brian.sol1.net/svg/?page_id=49#comment-32693 What you say makes sense here, I think I'm wrong about this. What you say makes sense here, I think I’m wrong about this.

]]> By: Olaf http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/comment-page-1/#comment-32685 Olaf Sat, 13 Dec 2008 12:32:59 +0000 http://brian.sol1.net/svg/?page_id=49#comment-32685 No, clearly tan(3 * 22) is correct, because there is no specific rule for accumulation in SVG, therefore it applies what is defined in SMIL and this is the addition of the values of the animated attribute and not some multiplication of some abstract effect. How to calculate the animation effect, is much better described in SMIL2 and SMIL3. This results in a clear procedure and leads clearly to the correct result, simply because the effect of cumulation is calculated much earlier than that of the relation to the underlying value, what is (only) modified for animateTransform by SVG. I provided exhaustive test for this issues about additive and cumulative behaviour for the SVGT 1.2 test suite, testing all combinations for from-to, from-by, by and values animations. No, clearly tan(3 * 22) is correct, because there is no specific rule for accumulation in
SVG, therefore it applies what is defined in SMIL and this is the addition of the
values of the animated attribute and not some multiplication of some abstract effect.

How to calculate the animation effect, is much better described in SMIL2 and SMIL3.
This results in a clear procedure and leads clearly to the correct result, simply because
the effect of cumulation is calculated much earlier than that of the relation to the
underlying value, what is (only) modified for animateTransform by SVG.

I provided exhaustive test for this issues about additive and cumulative behaviour for
the SVGT 1.2 test suite, testing all combinations for from-to, from-by, by and values
animations.

]]>