User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.99 Safari/537.22 Steps to reproduce: Go here: http://jsfiddle.net/K7Ukb/8/ on this browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20130304 Firefox/21.0 or this browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/20100101 Firefox/19.0 Click circle to animate zoom in. Click rectangle to reset zoom out. Actual results: The animation is very choppy with potential to hang the browser. This is a stripped down version of a more complex svg UI I am working on. More elements degrade performance even further. On the full version with more elements, this animation once even crashed my entire machine. I have tried different animation techniques, such as enlarging the circle rather than zooming in the viewbox, but the result is the same. I dont think this is just a viewbox issue or even an SVG issue. The bottleneck seems to be in the repainting. Expected results: Animation should be smooth or at least finish on time.

Saw the jerkiness on FF 19.0.2, 23.0a1 (2013-04-02) Mac OS X 10.8.3. It seems to be a regression, it's not repro on FF 4.0.1. I'll come back with a regression range.

Last good nightly: 2012-12-17 First bad nightly: 2012-12-18 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8a1314aa449&tochange=2e70b718903a

Thanks Paul. Given this is a regression I'm requesting tracking for all active branches.

The status flags on bug 822378 seem to imply that this has been a problem since Firefox 20 (see uplifts). Does this impact any major web properties?

(In reply to Alex Keybl [:akeybl] from comment #4) > The status flags on bug 822378 seem to imply that this has been a problem > since Firefox 20 (see uplifts). Does this impact any major web properties? It's hard to say. I'm not sure how popular jsfiddle.net is or if there are other websites using this. CCing Matthew just in case there's information on SUMO or Input which might be indicative of a major web property being affected.

FWIW, jsfiddle.net is ranked 2153rd on Alexa.com

jsfiddle.net is quite popular among web developers, but that's not relevant -- it's basically just a pastebin for testcases. :) This bug doesn't affect jsfiddle.net -- that's just where the reporter happened to post his testcase.

FWIW, I'm not seeing anything on Input or SUMO at this point. I've done some queries for general animation jerkiness and other common expressions. We can monitor it throughout the week though.

This is specific to animation of a viewBox. That's probably not so common.

Thanks Matt and Robert. Please renominate for release tracking if/when a major web property is impacted. For now, it'd be great if we could help those affected with a workaround or quick resolution. The fact that we're not tracking this issue does not mean that we wouldn't uplift it into pre-release versions of Firefox if a low risk fix was found. Please nominate for uplift if we do find a fix.

It would be helpful if someone could attach a reduced testcase without the raphiel.js dependency.

(In reply to Alex Keybl [:akeybl] from comment #10) > Thanks Matt and Robert. > > Please renominate for release tracking if/when a major web property is > impacted. I'm the original reporter and the project where i was having this problem has gone live since. It's a B2B site for Google. As it's a B2B site, it's only had about 30,000 uniques since launch a few weeks ago. But it did get a good amount of press and it's a pretty major brand and competitor of Mozilla's. And a great showcase for Chrome's SVG advantages ;) check it out: http://www.howtogomo.com/fvm/en/d/ Also, in reply to @Robert Longson: >This is specific to animation of a viewBox. That's probably not so common. I dont think it is specific to viewBox. I also tried animating the size of the circle while keeping the viewbox fixed. It had the same problem. The choppiness is also highly resolution-dependent. Let me know if a jsfiddle is needed for that.

One issue is bug 847653. Another is that SVGSVGElement::ChildrenOnlyTransformChanged is calling nsLayoutUtils::PostRestyleEvent and passing nsChangeHint_RepaintFrame.

(In reply to Jonathan Watt [:jwatt] from comment #14) > Another is that > SVGSVGElement::ChildrenOnlyTransformChanged is calling > nsLayoutUtils::PostRestyleEvent and passing nsChangeHint_RepaintFrame. Span that out into bug 870003, since fixing that doesn't completely fix the issues here.

In this testcase I'm seeing pretty jerky animation, and at one point the line gets thinner rather than thicker.

Here's a log of the invalidation and painting that's going on during the animation. Search for "Invalidating entire layer" in the log. Every time that happens, the dimensions of the "visible" rect of the last OGLThebesLayer in the "Painting --- after optimization" block that follows increases to twice what it was. This looks to be the problem, since I believe we'll then paint into an increasingly larger surface, doing way more work than we should be doing. The "Invalidating entire layer" is no doubt being triggered by ChooseScaleAndSetTransform jumping to the next scale as the transform hits certain thresholds.

Same thing happens with layers.acceleration.disabled set to true.

I don't anticipate getting to this any time soon, and given comment 18 this would be best to have someone who's worked on layers take a look.

The string "Invalidating entire layer" no longer appears in the log output nowadays. Here is an up to date log from when the 'even simpler testcase' animates with layout.display-list.dump-content set to true.

Markus confirms that I originally misunderstood the logging code in comment 18, and certainly things look good in the current log. (And the reason "Invalidating entire layer" doesn't appear is because I didn't have nglayout.debug.invalidation set.) We also seem to visually perform fine now. So closing this as WORKSFORME.