<animateTransform accumulate="sum"> should multiply, not sum. Since we sum repeats, we get "jumps" on each repeat.

I don't have time to look at this right now (exam this afternoon) but I'm pretty sure I've gone over this before: http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/

See also the following regarding scale animations: http://brian.sol1.net/svg/animatetransform-issues/by-animation-and-scale-transformations/

Are you claiming this bug is invalid?

(In reply to comment #4) > Are you claiming this bug is invalid? I've yet to look into it. I'm fairly sure what we do with accumulating is consistent with the interpretation taken in the SVGT1.2 test suite (see link in comment 2). I'm really not sure how this should behave If you have: <animateTransform type="transform" from="1" to="2" accumulate="sum" ... /> you will get jumps. So too: <animateTransform type="scale" from="1" to="2" additive="sum" ... /> The difficulty is that the neutral value of a scale transform is 0,0 whilst the identity value is 1,1. See: http://lists.w3.org/Archives/Public/www-svg/2008Dec/0045.html, and link in comment 3. Maybe we need different behaviour for scale transformations when accumulating?

(In reply to comment #5) > The difficulty is that the neutral value of a scale transform is 0,0 whilst the > identity value is 1,1. Hmm, that's not quite right. But http://lists.w3.org/Archives/Public/www-svg/2008Dec/0045.html explains why we use addition within an animation function and post-multiplication when combining values in the sandwich. (I'm not necessarily supporting this interpretation except that it is the one used in the SVGT1.2 test suite.) I still need to look into this properly.

Ok, I've looked into this now. The best explanation is still: http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/ which I've now fixed so it should be viewable in trunk builds. Basically, the author of several tests in the SVGT1.2 Test Suite has differentiated between the concepts of accumulation and addition. Indeed the wording of the spec allows this: > The animation effect for 'animateTransform' is post-multiplied to the > underlying value for additive 'animateTransform' animations (see below) > instead of added to the underlying value, due to the specific behavior of > 'animateTransform'. http://dev.w3.org/SVG/profiles/1.1F2/publish/animate.html#AnimateTransformElement That is, post-multiplication is only required when adding to the underlying value. Elsewhere we use we just add the parameters together. This behaviour is tested in the following tests: http://www.w3.org/Graphics/SVG/Test/20080912/htmlObjectHarness/animate-elem-212-t.html http://www.w3.org/Graphics/SVG/Test/20080912/htmlObjectHarness/animate-elem-213-t.html http://www.w3.org/Graphics/SVG/Test/20080912/htmlObjectHarness/animate-elem-214-t.html http://www.w3.org/Graphics/SVG/Test/20080912/htmlObjectHarness/animate-elem-215-t.html http://www.w3.org/Graphics/SVG/Test/20080912/htmlObjectHarness/animate-elem-216-t.html http://www.w3.org/Graphics/SVG/Test/20080912/htmlObjectHarness/animate-elem-217-t.html If we use post-multiplication for cumulative animation we fail these tests. As I've noted elsewhere this interpretation is not obvious, particularly as SMILANIM 3.3.1 seems to suggest some relationship between cumulative animation and additive animation when it says: > [The cumulative attribute] is ignored if the target attribute value does not support addition Nevertheless it is the interpretation used in the test suite. Interoperability: Opera uses the same behaviour as we do, i.e. adds animation parameters for cumulative animation. For the test URL: http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-elem-81-t.svg, Opera shows the same jumping behaviour as reported in this bug. WebKit and Batik use post-multiplication and WebKit fails the above-mentioned tests for that reason (I couldn't test Batik since I was getting unrelated errors which stopped the tests from running). This behaviour can be easily checked with the following test graphic: http://brian.sol1.net/svg/images/svg/accumulate-transform.svg If the arrow ends up inside the red outline it's using post-multiplication. If it end up in the black outline it's summing the animation parameters. So I think we should resolve this as invalid (and encourage WebKit to fix their implementation). Any objections?

Thanks for the analysis, Brian! In my view, SVG 1.1 sometimes conflates animation addition and accumulation. For example, section 19.2.8 http://www.w3.org/TR/SVG/animate.html#AdditionAttributes is entitled "Attributes that control whether animations are additive", yet it talks about additive and cumulative animations. It also calls the set of attributes { additive, accumulate } the "animation addition attributes". In http://www.w3.org/TR/SVG/animate.html#AnimationAttributesAndProperties the table lists which types of values can have additive animations, but IMO it makes sense to interpret that column as also defining whether it can have a cumulative animation (and we did point that out explicitly in SVG Tiny 1.2). So even though SVG defines special behaviour for compositing additive <animateTransform> values with their underlying values and not for cumulative animations, I wouldn't say that it's necessarily a deliberate omission. At the very least, the spec should point this out. Anyway, I agree with your analysis. With a strict reading of the current SVG spec, as Olaf says in the comments of your blog post, since SVG does not explicitly override cumulative animation behaviour for <animateTransform>, we are left just with the formulae in SMIL, and as he states we then have no reason to interpret the "*" and "+" operators in those formulae as being anything different from its usual interpretation. We do have to interpret the type of value that <animateTransform> works on as being a simple matrix for these operators to work, rather than a transform list. (But we already have to consider it so; that's part of <animateTranform>'s special nature, I think.) I will bring the issue in this test up with the WG, and if/when it gets changed, I'll mark this bug as invalid.

Perhaps I was wrong about treating the values that <animateTransform> works on as matrices, as that obviously will fail for something like: <animateTransform type="translate" from="0,0" to="10,10" dur="1s" repeatCount="4"/> because at the start of the fourth repetition, you would have: f_4(t) = (f(d) * 4) + f(t - (4*d)) = [ 1 0 10 ] * 4 + [ 1 0 0 ] [ 0 1 10 ] [ 0 1 0 ] and you don't want those scale values to get up to 4. So the accumulation must work on the parameter values of the transform animation -- i.e. what's in the values="", from="", to="", etc. They're simple number (or vectors of numbers) that we can add together and multiply with a scalar. I don't think SVG spec has any wording to state that this is the space of values that <animateTransform> works on when computing its animation effect function, and that this value is then treated as a transformation matrix when adding to underlying animations or the base value, but I guess this is the only reasonable interpretation. (It's also not clear whether the post-multiplication that is performed with additive animations just computes a new single transform item -- which could be of the same type if say two <animateTransform type="scale">s were added, or just a single matrix() item otherwise -- or whether the post-multiplication builds up a list of transform items. The spec talks about the rendered behaviour, but the values placed in the DOM could follow either of these approaches.)

Here's a test showing a cumulative scale animation from 0 to 1: http://people.mozilla.org/~cmccormack/tests/cumulative-transform.svg I found three different behaviours, and I noted in the test how I think they were derived.

I've added some wording to the spec that defines transform animation accumulation as working in the transform parameter space, rather than the transformation matrix it represents in the end. See the last couple of paragraphs of http://dev.w3.org/SVG/profiles/1.1F2/publish/animate.html#AnimateTransformElement. Let me know if you think it needs more details. As I write this, I'm wondering what should happen for type="rotate" animations that specify centre points, e.g.: <animateTransform ... type="rotate" from="10 50,50" to="20 50,50" repeatCount="3" accumulate="sum"/> Should this go: 1st repetition: rotate(10 50,50) -> rotate(20 50,50) 2nd repetition: rotate(30 50,50) -> rotate(40 50,50) 3rd repetition: rotate(50 50,50) -> rotate(60 50,50) or 1st repetition: rotate(10 50,50) -> rotate(20 50,50) 2nd repetition: rotate(30 100,100) -> rotate(40 100,100) 3rd repetition: rotate(50 150,150) -> rotate(60 150,150) ?

As discussed on IRC, I think for consistency the rotation coordinates should also be added--i.e. the latter. It's counter-intuitive but cumulative animation often produces such counter-intuitive results if the animation isn't "zero-based". Even the examples given in SMIL 3 produce "jumping" behaviour: http://www.w3.org/TR/SMIL/smil-animation.html#animationNS-AddAndCum Often, to produce cumulative animation without jumps, one needs to rework the content so the animation starts from some sort of zero-point. In future, we'd like to see a kind of rotation that centres around an element's bounding box (and perhaps centre of mass?). Hopefully that will allow some 'rotate+centre' animations to be replaced with simple 'rotate' animations.

OK, the spec now points the rotate() thing out. The test has been updated, too, so we no longer fail it.