847653 - Scaling transform animation can cause severe jank and sometimes misrender on Firefox for Mac

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Owen Masback]

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.

Comment 1

[Paul Silaghi, QA [:pauly]]

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.

Comment 2

[Paul Silaghi, QA [:pauly]]

Last good nightly: 2012-12-17
First bad nightly: 2012-12-18

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8a1314aa449&tochange=2e70b718903a

Comment 3

[u279076]

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

Comment 4

[Alex Keybl [:akeybl]]

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?

Comment 5

[u279076]

(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.

Comment 6

[u279076]

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

Comment 7

[Daniel Holbert [:dholbert]]

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.

Comment 8

[Matt Grimes [:Matt_G]]

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.

Comment 9

[Robert Longson [:longsonr]]

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

Comment 10

[Alex Keybl [:akeybl]]

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.

Comment 11

[Jonathan Watt [:jwatt]]

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

Comment 12

[Owen Masback]

(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.

Comment 13

[Jonathan Watt [:jwatt]]

Attachment: reduced testcase

Comment 14

[Jonathan Watt [:jwatt]]

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

Comment 15

[Jonathan Watt [:jwatt]]

(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.

Comment 16

[Jonathan Watt [:jwatt]]

Attachment: even simpler testcase

Comment 17

[Jonathan Watt [:jwatt]]

Attachment: even simpler testcase

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

Comment 18

[Jonathan Watt [:jwatt]]

Attachment: invalidation and paint log

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.

Comment 19

[Jonathan Watt [:jwatt]]

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

Comment 20

[Jonathan Watt [:jwatt]]

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.

Comment 21

[Jonathan Watt [:jwatt]]

Attachment: Log output during animation of 'even simpler testcase' with layout.display-list.dump-content set to true

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.

Comment 22

[Jonathan Watt [:jwatt]]

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.