1332558 - Laggy drawing of SVG on Windows when hardware acceleration is enabled

Status: NEW

(Core :: Graphics, defect, P3)

Description

[jeffdougson]

Attachment: atoms.svg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce:

Load the attached SVG file in Firefox on Windows.



Actual results:

Whole browser UI hangs, and never comes back. Windows eventually suggests to kill Firefox.

Witnessed on multiple PCs. At least one of them is running Firefox 50.1.0
on Windows 10 1607 OS Build 14393.693. (Haven't confirmed the other.)



Expected results:

The SVG should render as it does on other browsers/platforms.

Comment 1

[Timothy Nikkel (:tnikkel)]

Seems snappy on OS X, laggy (but doesn't hang) when I test on Windows. This suggests it's a gfx issue.

Comment 2

[Loic]

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c89981f5cbe73
c3268c283a5414d5894587631ba&tochange=f0e64326ce2bf4d3f103cfcd09280123868e3aa1

Bas Schouten — Bug 1293586: Don't use command lists for an effect when that command list already has an effect with a command list used inside of it. r=mstange


The increase of CPU use is very visible.

Comment 3

[Bas Schouten (:bas.schouten)]

I cannot reproduce this freezing or anything along those lines, it isn't fast, this is true, it is also likely regressed by the aforementioned bugfix, but that bugfix addressed a situation where a freeze actually occurred.

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Bas Schouten (:bas.schouten) from comment #3)
> I cannot reproduce this freezing or anything along those lines, it isn't
> fast, this is true, it is also likely regressed by the aforementioned
> bugfix, but that bugfix addressed a situation where a freeze actually
> occurred.

For the record, this was on Windows 10, with D2D 1.1 enabled. Could someone for whom this freezes send their about:support?

Comment 5

[jeffdougson]

Attachment: about-support.json from machine exhibiting problem

Here's the output of `about:support` from the first machine we saw this on. I believe the other machine is supposed to be identical.

Comment 6

[Loic]

Attachment: about-support.txt

Comment 7

[Bas Schouten (:bas.schouten)]

(In reply to Loic from comment #6)
> Created attachment 8829689 [details]
> about-support.txt

Can you disable e10s and send it then? And also verify it's still happening?

Comment 8

[Loic]

It's more visible with e10s disabled, especially CPU use.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

I did some poking at this. I can very-much reproduce the hang on Firefox 50.1 when hardware acceleration is enabled. With HWA disabled, it loads instantaneously. But then the testcase loads much faster for me with 51 and 52 (a bit of lag before drawing anything, then the whole things appears in one shot). And then during the 53 cycle, it got laggy with different parts of the image drawing before others, but no hanging. In comparison, the testcase loads instantaneously with Chrome and Edge.

On Nightly, disabling e10s doesn't appear to make much of a difference. Disabling hardware acceleration via about:preferences makes it load with less lag, albeit still not as fast as it was for 51/52 or Chrome/Edge.

Using mozregression, bug 1300338 is what fixed the hang for 51 and 52. Bug 1283302 is what made the drawing more laggy and piecemeal.

Given the results above, I'm calling 51/52 unaffected and setting 53/54 as fix-optional since there's still a perf issue here, but not as severe as originally filed. And it's still sadmaking that basic layers are faster than D3D11 here :(

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
> I did some poking at this. I can very-much reproduce the hang on Firefox
> 50.1 when hardware acceleration is enabled. With HWA disabled, it loads
> instantaneously. But then the testcase loads much faster for me with 51 and
> 52 (a bit of lag before drawing anything, then the whole things appears in
> one shot). And then during the 53 cycle, it got laggy with different parts
> of the image drawing before others, but no hanging. In comparison, the
> testcase loads instantaneously with Chrome and Edge.
> 
> On Nightly, disabling e10s doesn't appear to make much of a difference.
> Disabling hardware acceleration via about:preferences makes it load with
> less lag, albeit still not as fast as it was for 51/52 or Chrome/Edge.
> 
> Using mozregression, bug 1300338 is what fixed the hang for 51 and 52. Bug
> 1283302 is what made the drawing more laggy and piecemeal.
> 
> Given the results above, I'm calling 51/52 unaffected and setting 53/54 as
> fix-optional since there's still a perf issue here, but not as severe as
> originally filed. And it's still sadmaking that basic layers are faster than
> D3D11 here :(

I'm really surprised this regressed in 53, I don't think any code landed there in is area, Lee, can you think of anything?

Also, yes, I was testing on 53, I guess that's why I couldn't see the hang, maybe?

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Given that the "regression" in 53 was due to changing the paint delay, is it possible we're just trying to do more right away which ends up slowing things down a bit overall?

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

This sounds nice to fix, but since it isn't too serious of a perf regression, I'm dropping the tracking flag.  But, if you do end up working on this and landing a patch, please request uplift as far as you think reasonable.

Comment 13

[Lee Salzman [:lsalzman]]

(In reply to Bas Schouten (:bas.schouten) from comment #10)
> (In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
> > I did some poking at this. I can very-much reproduce the hang on Firefox
> > 50.1 when hardware acceleration is enabled. With HWA disabled, it loads
> > instantaneously. But then the testcase loads much faster for me with 51 and
> > 52 (a bit of lag before drawing anything, then the whole things appears in
> > one shot). And then during the 53 cycle, it got laggy with different parts
> > of the image drawing before others, but no hanging. In comparison, the
> > testcase loads instantaneously with Chrome and Edge.
> > 
> > On Nightly, disabling e10s doesn't appear to make much of a difference.
> > Disabling hardware acceleration via about:preferences makes it load with
> > less lag, albeit still not as fast as it was for 51/52 or Chrome/Edge.
> > 
> > Using mozregression, bug 1300338 is what fixed the hang for 51 and 52. Bug
> > 1283302 is what made the drawing more laggy and piecemeal.
> > 
> > Given the results above, I'm calling 51/52 unaffected and setting 53/54 as
> > fix-optional since there's still a perf issue here, but not as severe as
> > originally filed. And it's still sadmaking that basic layers are faster than
> > D3D11 here :(
> 
> I'm really surprised this regressed in 53, I don't think any code landed
> there in is area, Lee, can you think of anything?
> 
> Also, yes, I was testing on 53, I guess that's why I couldn't see the hang,
> maybe?

I am not aware of anything on my end of things that changed that might influence this.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix for 57, not sure if this is still an issue so once again, I'll let it drop from triage, unless we have new reports with steps to reproduce.

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

I don't see this in 58, at least not a full hang.  Is it still around?