From reading the spec, I would expect the following to produce an indeterminate progress spinner which rotates 30 degrees every 0.5 seconds. In testing, it rotates 30 degrees once, and then proceeds to go insane, jumping all over the viewport. It looks like cX and cY are being incremented along with the angle during each iteration, and I can't really think of any reason why that would be desirable. <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <g width="50" height="50" id="spinner" > <animateTransform attributeName="transform" type="rotate" from="0,25,25" to="30,25,25" dur="0.5s" repeatCount="indefinite" calcMode="discrete" additive="sum" accumulate="sum" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(0,25,25)" fill-opacity="0.50" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(30,25,25)" fill-opacity="0.05" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(60,25,25)" fill-opacity="0.10" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(90,25,25)" fill-opacity="0.15" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(120,25,25)" fill-opacity="0.20" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(150,25,25)" fill-opacity="0.25" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(180,25,25)" fill-opacity="0.25" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(210,25,25)" fill-opacity="0.30" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(240,25,25)" fill-opacity="0.35" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(270,25,25)" fill-opacity="0.40" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(300,25,25)" fill-opacity="0.45" /> <polygon points="22,0 28,0 27,12 23,12" fill="#000" x="22" transform="rotate(330,25,25)" fill-opacity="0.50" /> </g> </svg> I get the correct behavior if I remove the calcMode, additive and accumulate attributes, but then everything is tweened, which is not what I want at all. No other browser handles this any better, so I can't tell if I'm simply misinterpreting the spec or if WebKit is genuinely broken in this regard. There certainly should be a way to specify a non-tweened rotation transform.
Supplying explicit values *does* work; i.e.: <animateTransform attributeName="transform" type="rotate" values="0,25,25; 30,25,25; 60,25,25; 90,25,25; 120,25,25; 150,25,25; 180,25,25; 210,25,25; 240,25,25; 270,25,25; 300,25,25; 330,25,25;" dur="0.5s" repeatCount="indefinite" calcMode="discrete" /> but this is rather unwieldy.
Supplying explicit values also introduces an unnatural pause between iterations which makes the animation jerky when it loops back around to start over.
Animation is somewhat broken, atm. We're still fixing lots of bugs in it. Thank you for the test case.
NOT a bug! By my opinion WebKit is correct. Problem with 1st testcase is this attribute: accumulate="sum" Also, rotation center is accumulated -> behaviour of Webkit is correct! I will attach corrected testcase...
Created attachment 80077 [details] working test
PS: ...tested with: Safari 5.0.2 Chrome 8.0.552.237
I fear the bug is still valid. I agree that the initially posted SVG should not do what the author might want it to, but it works exactly like the "working test". And that seems to be wrong. Compare it to other svg viewers.
(In reply to comment #7) > I fear the bug is still valid. I agree that the initially posted SVG should not do what the author might want it to, but ... Hello Dirk, thx for the note. I fear too :-( I made some additional tests and I can confirm, there is still bug... #1 problem resides NOT in "rotate" transform, BUT in computing of accumulated animations (accumulate="sum"). I will attach basic SVG for repeatCount="2" for testing purposes... #2 problem: calcMode="discrete" is ignored... --tested with-- Safari 5.0.2 (5533.18.5) Chrome 14.0.803.0 dev
Created attachment 99635 [details] SVG example exactly shows bug of Webkit animateTransform accumulate=sum calculation
(In reply to comment #8) > (In reply to comment #7) > > I fear the bug is still valid. I agree that the initially posted SVG should not do what the author might want it to, but ... > > Hello Dirk, thx for the note. I fear too :-( > > I made some additional tests and I can confirm, there is still bug... > > #1 problem resides NOT in "rotate" transform, BUT in computing of accumulated animations (accumulate="sum"). I will attach basic SVG for repeatCount="2" for testing purposes... > > #2 problem: calcMode="discrete" is ignored... > > --tested with-- > Safari 5.0.2 (5533.18.5) > Chrome 14.0.803.0 dev I'm unsure if that is right. We have the same animation like batik right now. I have to check it first. The problem on SVGTransform: We don't just add the translation on every repeat, it is like a matrix that gets _post multiplied_ to all previous transforms. Thats why I doubt that 25 after first iteration and 50 after second iteration is correct. Note that I changed the behavior of accumulation lately. We now calculate the distance from 0 to 100% for the first iteration 100% to 200% for the second iteration and so on. Again, we have to do some math to see who is right: opera+FF (match your test) or batik+WebKit (no translation). To calcMode=discrete: I can confirm that we don't have special handling for it. Nevertheless that is another topic. Can you open a new bug and add a test file please?
(In reply to comment #10) > I'm unsure if that is right. We have the same animation like batik right now. I have to check it first. The problem on SVGTransform: We don't just add the translation on every repeat, it is like a matrix that gets _post multiplied_ to all previous transforms. Thats why I doubt that 25 after first iteration and 50 after second iteration is correct. I understand, what you mean. It is good consideration. By my opinion, the rock-bottom of this probles lies in this claim: *Should be final animated-transformation after accumulation in 2 cycles: transform="rotate(60,50,50)"* ?? (animated from="0,25,25" to="30,25,25") Primary Question is: YES or NO? ================================ If confirmed YES, then Opera + FF are correct... > Note that I changed the behavior of accumulation lately. We now calculate the distance from 0 to 100% for the first iteration 100% to 200% for the second iteration and so on. It looks absolutely correct... the only possible "hanger" I see, is which value is iterated (transform matrix or XML attributes) I am not sure if we can iterate matrix...
(In reply to comment #10) > To calcMode=discrete: I can confirm that we don't have special handling for it. Nevertheless that is another topic. Can you open a new bug and add a test file please? FYI: It looks like this problem belongs here: https://bugs.webkit.org/show_bug.cgi?id=37250
(In reply to comment #12) > (In reply to comment #10) > > > To calcMode=discrete: I can confirm that we don't have special handling for it. Nevertheless that is another topic. Can you open a new bug and add a test file please? > > FYI: It looks like this problem belongs here: > > https://bugs.webkit.org/show_bug.cgi?id=37250 Both bugs are fixed in trunk, we're now matching Firefox/Opera nightlies behavior. calcMode=discrete being broken was obvious. The other bug with the rotation center is less obvious, but our trunk behavior is now correct: additive/accumulate will animate all functions of a SVGTransform type, like rotate: angle, center x and center y. Both bugs are covered with test cases in LayoutTests/svg/animations, so it's safe to close this bug. Happy SMILing!