RESOLVED FIXED 18209
Animation: SVG "rotate" transforms fail to obey the center point 
https://bugs.webkit.org/show_bug.cgi?id=18209
Summary Animation: SVG "rotate" transforms fail to obey the center point
Kay Summers
Reported 2008-03-29 11:58:51 PDT
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.
Attachments
working test (2.02 KB, image/svg+xml)
2011-01-25 10:20 PST, MH 		no flags
Details
SVG example exactly shows bug of Webkit animateTransform accumulate=sum calculation (2.43 KB, image/svg+xml)
2011-07-04 09:10 PDT, MH 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Kay Summers
Comment 1 2008-03-29 12:08:46 PDT
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.
Kay Summers
Comment 2 2008-03-29 12:39:08 PDT
Supplying explicit values also introduces an unnatural pause between iterations which makes the animation jerky when it loops back around to start over.
Eric Seidel (no email)
Comment 3 2008-04-13 22:43:19 PDT
Animation is somewhat broken, atm. We're still fixing lots of bugs in it. Thank you for the test case.
MH
Comment 4 2011-01-25 10:18:01 PST
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...
MH
Comment 5 2011-01-25 10:20:12 PST
Created attachment 80077 [details] working test
MH
Comment 6 2011-01-25 10:28:15 PST
PS: ...tested with: Safari 5.0.2 Chrome 8.0.552.237
Dirk Schulze
Comment 7 2011-07-04 02:07:45 PDT
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.
MH
Comment 8 2011-07-04 09:04:41 PDT
(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
MH
Comment 9 2011-07-04 09:10:34 PDT
Created attachment 99635 [details] SVG example exactly shows bug of Webkit animateTransform accumulate=sum calculation
Dirk Schulze
Comment 10 2011-07-04 09:26:27 PDT
(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?
MH
Comment 11 2011-07-04 10:08:02 PDT
(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...
MH
Comment 12 2011-07-04 10:58:31 PDT
(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
Nikolas Zimmermann
Comment 13 2012-05-03 00:45:59 PDT
(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!
Note You need to log in before you can comment on or make changes to this bug.