Closed Bug 1165732 Opened 9 years ago Closed 9 years ago

Firefox running very slow on Windows starting with version 38 due to hardware acceleration

Categories

(Core :: Graphics, defect)

38 Branch
Unspecified
Windows
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox38 + wontfix
firefox38.0.5 + fixed
firefox39 + fixed
firefox40 --- fixed
firefox41 --- fixed
firefox-esr38 39+ fixed
relnote-firefox --- 39+

People

(Reporter: aryx, Assigned: jrmuizel)

References

Details

(Keywords: regression)

Attachments

(3 files, 2 obsolete files)

Saw at least 3 reports of this issue today (all run Windows 7, compare the about:support content I will attach to this bug).

Description from a user (translated):

The browser is slow and janks in general, typed characters are shown with 1-3 seconds delay.

It works fine in safe mode, with hardware acceleration disabled and after updating the graphic drivers

Device specs: (Toshiba Portégé M100, Pentium M 1200 MHz, 2GB DDR1, IDE-SSD 60GB Kingston, Win7 Pro SP1).
The similarities in the Graphics section of about:support for report 1 & 2:

Direct2D aktiviert: Wurde auf Grund Ihrer Grafiktreiberversion blockiert.
DirectWrite aktiviert: false (6.2.9200.17292)
GPU #2 aktiv: false
GPU-beschleunigte Fenster: 1/1 Direct3D 11 WARP (OMTC)
Karten-Beschreibung: Standard-VGA-Grafikkarte
Karten-RAM: Unknown
Karten-Treiber: vga framebuf vga256 vga64k
Treiber-Datum: 6-21-2006
Treiber-Version: 6.1.7600.16385
WebGL-Renderer: Wurde auf Grund Ihrer Grafiktreiberversion blockiert.
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
If I understand the problem here correctly it's due to -not- having hardware acceleration, possibly somehow related to WARP but that's hard to say without having a machine that reproduces the issue. One possibility is that this is a problem on Single core machines? The Pentium M 1200 reported by the reporter is a very old single core machine.

Milan, can we dig up a single core laptop in the Toronto office and see how well running firefox with WARP compares there to running unaccelerated Firefox (just setting layers.d3d11.disable-warp on a blacklisted machine).
Flags: needinfo?(bas)
Flags: needinfo?(milan)
I'll look, but I doubt it.  In the meantime:

Bas, what are our options in 38 for blocklisting these devices/driver?

From the first comment, it appears that updating the driver makes things better, even with HW acceleration?

Could AdBlock somehow be interfering? Can we ask the users to run with a clean profile, but not in safe mode?
Flags: needinfo?(milan)
Flags: needinfo?(bas)
Flags: needinfo?(archaeopteryx)
(In reply to Milan Sreckovic [:milan] from comment #4)
> From the first comment, it appears that updating the driver makes things
> better, even with HW acceleration?
Running it in Safe Mode lets run Firefox normal. Some people reported return to normal performance after a graphics driver update.

> Could AdBlock somehow be interfering?
It's not listed in every affected profile and...

> Can we ask the users to run with a clean profile, but not in safe mode?
Report from one user that issue also affects new profiles.
Flags: needinfo?(archaeopteryx)
based on the amount of user feedback this is generating, i will turn up the urgency of this...

other affected configurations (seems to hit all manufacturers, with generic windows vga drivers present):
Direct2D aktiviert: Wurde auf Grund Ihrer Grafiktreiberversion blockiert. 
DirectWrite aktiviert: false (6.2.9200.17292) 
Geräte-ID: 0x0156 
GPU #2 aktiv: false 
GPU-beschleunigte Fenster: 1/1 
Direct3D 11 WARP (OMTC) 
Karten-Beschreibung: Standard-VGA-Grafikkarte 
Karten-RAM: Unknown 
Karten-Treiber: vga framebuf vga256 vga64k 
Subsys-ID: 064b1025 
Treiber-Datum: 6-21-2006 
Treiber-Version: 6.1.7600.16385 
Vendor-ID: 0x8086 
WebGL-Renderer: Wurde auf Grund Ihrer Grafiktreiberversion blockiert.
windowLayerManagerRemote: true 
AzureCanvasBackend: skia 
AzureContentBackend: cairo 
AzureFallbackCanvasBackend: cairo 
AzureSkiaAccelerated: 0

Direct2D aktiviert: Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 257.21 zu aktualisieren. 
DirectWrite aktiviert: false (6.1.7600.16385) 
Geräte-ID: 0x0649 
GPU #2 aktiv: false 
GPU-beschleunigte Fenster: 1/1 Direct3D 11 WARP (OMTC) 
Karten-Beschreibung: Standard-VGA-Grafikkarte 
Karten-RAM: Unknown 
Karten-Treiber: vga framebuf vga256 vga64k 
Subsys-ID: 00000000 
Treiber-Datum: 6-21-2006 
Treiber-Version: 6.1.7600.16385 
Vendor-ID: 0x10de 
WebGL-Renderer: Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 257.21 zu aktualisieren. windowLayerManagerRemote: true 
AzureCanvasBackend: skia 
AzureContentBackend: cairo 
AzureFallbackCanvasBackend: cairo 
AzureSkiaAccelerated: 0

Direct2D aktiviert: Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 9.6 zu aktualisieren. 
DirectWrite aktiviert: false (6.2.9200.16492) 
Geräte-ID: 0x7149 
GPU #2 aktiv: false 
GPU-beschleunigte Fenster: 0/1 Basic (OMTC) Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 9.6 zu aktualisieren. 
Karten-Beschreibung: Standard-VGA-Grafikkarte 
Karten-RAM: Unknown 
Karten-Treiber: vga framebuf vga256 vga64k 
Subsys-ID: 200517aa 
Treiber-Datum: 6-21-2006 
Treiber-Version: 6.1.7600.16385 
Vendor-ID: 0x1002 
WebGL-Renderer: Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 9.6 zu aktualisieren. windowLayerManagerRemote: true 
AzureCanvasBackend: skia 
AzureContentBackend: cairo 
AzureFallbackCanvasBackend: cairo 
AzureSkiaAccelerated: 0 (#0) Error: Failed to allocate a surface due to invalid size Size(0,1) 
(#4132) Error: Failed to allocate a surface due to invalid size Size(0,1) 
(#4133) Error: Failed to allocate a surface due to invalid size Size(0,1) 
(#4134) Error: Failed to allocate a surface due to invalid size Size(0,1) 
(#4135) Error: Failed to allocate a surface due to invalid size Size(0,1) 
(#4136) Error: Failed to allocate a surface due to invalid size Size(0,1)
Severity: normal → critical
Keywords: regression
Philipp is pulling Feedback ID's, User Advocacy will look for anything interesting in their submitted Remote Troubleshooting data from there.
(In reply to Milan Sreckovic [:milan] from comment #4)
> I'll look, but I doubt it.  In the meantime:
> 
> Bas, what are our options in 38 for blocklisting these devices/driver?
> 
> From the first comment, it appears that updating the driver makes things
> better, even with HW acceleration?
> 
> Could AdBlock somehow be interfering? Can we ask the users to run with a
> clean profile, but not in safe mode?

We could simply look for a single core and say if there's a single core we disable OMTC altogether, or just disabling WARP. It's tricky to say if this is a good idea. There's a couple of things we need to consider here:

1) On a single core machine, things like textboxes and such will perform better when not using OMTC when not using HWA rendering.
2) It will require us to maintain the non-OMTC codepath. We need to do this for several reasons at the moment anyway so I don't think this will be much of an issue.
3) Things like jank in scrolling might be -worse- without OMTC/WARP even on a single core-machine, it's a hard tradeoff to make.
Flags: needinfo?(bas) → needinfo?(milan)
(In reply to Bas Schouten (:bas.schouten) from comment #8)
> We could simply look for a single core and say if there's a single core we
> disable OMTC altogether, or just disabling WARP. It's tricky to say if this
> is a good idea. There's a couple of things we need to consider here:
The issue doesn't seem to be restricted to single cores, got a report from an admin that this also affects machines with Intel Pentium G3420 which is a dual core: http://ark.intel.com/products/77775/Intel-Pentium-Processor-G3420-3M-Cache-3_20-GHz?wapkw=g3420
i was able to get to the fault state on an older machine (with a Intel(R) Q45/Q43 graphics chipset) rather easily by going into the windows device manager & uninstalling the existing graphics driver without rebooting immediately after that (then the default microsoft vga driver seems to be in use).

the narrowed down regression range is: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=92aeec7102fe&tochange=96c8ca415e45
so regressed by the work in bug 1147728

switching layers.d3d11.disable-warp to true helps after a restart of firefox as does reinstalling the non-generic ms vga driver.
Blocks: 1147728
[Tracking Requested - why for this release]:
[Tracking Requested - why for this release]:
this bug is making firefox unusable (constant slowdowns and multi-second delays of any input) for a subsection of windows users who do not have a dedicated graphics driver installed and are using the generic microsoft vga driver with older graphics hardware (the exact scope is still unclear as far as i know).
Given what we know, if we could get a patch ready really soon, I think it may be a good idea to get it into the 38.0.5 RC that's going to build tomorrow.
The only thing I can think of us doing is blocklisting WARP when we have the generic vga driver, perhaps independently of the devices, and just going to software.  Bas, what do you think?  Can we do this with the downloadable list?

Assigning to Nical, Bas has a few tracked bugs, in case we need somebody to get the patches made and through.
Assignee: nobody → nical.bugzilla
Flags: needinfo?(milan) → needinfo?(bas)
OS: Unspecified → Windows
It looks like I've arrived at the same data though different means, which is nice.

The following settings strongly correlated with feedback on slowness:
 * GPU = Standard VGA Graphics Adapter                      4x higher frequency of slowness complaints
 * directWriteEnabled = False/AzureContentBackend = cairo   1.7x higher frequency of slowness complaints
       (These settings indicate an XP / Vista issue)

Ping me if you're interested in tabular data for all of the best correlates.  I excluded add-ons since they were not suspected and make the data interpretation more difficult.

Thanks
I experienced problems of slowness in some of my machines since monday 18th

The problem began when upgrading to 38.0.1
In safe mode will not experience problems
It does not happen in previous versions (below 38.0)

The workarounds I've found to the problem:

1. Disable hardware acceleration in FF
2. Update the video drivers to the latest version (this fixes the problem in many cases)

In all cases where the problem occurs the video drivers are outdated or are generic

I have tested in virtualbox with newly installed systems and the problem also exists. In these cases disabling hardware acceleration avoids the problem.

I tried FF's newly installed without any profile and the problem persists. So the problem also affects new profiles.
As far as I'm concerned when a user is using the 'Generic VGA Graphics Adapter' we blacklist everything we possibly can.
Flags: needinfo?(bas)
Lawrence, Sylvestre, heads up we will be asking for a full uplift of the fix for this to the release and all channels in between.
Flags: needinfo?(sledru)
Flags: needinfo?(lmandel)
The go to build of 38.0.5 RC is today (starting in a few hours).
Do you expect to have a fix today?
Flags: needinfo?(sledru)
Yessir.
Assignee: nical.bugzilla → jmuizelaar
Flags: needinfo?(lmandel)
I have a patch written, that I'm just building now.
Attached patch Block vga driver (obsolete) — Splinter Review
Attachment #8608794 - Flags: review?(bas)
Attachment #8608794 - Flags: review?(bas) → review+
Jeff, you have my a+ for the landing in m-r. Please land it asap.
We need to have the RC live tomorrow (Friday).
Tracking as it is a severe issue on some system. I don't think we will do a dot release but wait for 38.0.5 to go live.
Attached patch Block vga driver (obsolete) — Splinter Review
This a tested version. The only change was to make gfxCriticalError not assert.
Attachment #8608794 - Attachment is obsolete: true
Attachment #8608813 - Flags: review+
Comment on attachment 8608813 [details] [diff] [review]
Block vga driver

Approval Request Comment
[Feature/regressing bug #]: dunno
[User impact if declined]: Slow firefox
[Describe test coverage new/current, TreeHerder]: Not yet
[Risks and why]: Should be low risk as it is just a blacklist
[String/UUID change made/needed]: None

Taking it to all channel.
Attachment #8608813 - Flags: approval-mozilla-release+
Attachment #8608813 - Flags: approval-mozilla-esr38+
Attachment #8608813 - Flags: approval-mozilla-beta+
Attachment #8608813 - Flags: approval-mozilla-aurora+
Attached patch Block vga driverSplinter Review
Approval Request Comment
[Feature/regressing bug #]: Enabling WARP
[User impact if declined]: Very slow firefox with VGA driver
[Describe test coverage new/current, TreeHerder]: I tested locally and it worked
[Risks and why]: Hopefully low, shouldn't introduce new code paths.

This time with a commit message.
Attachment #8608813 - Attachment is obsolete: true
Attachment #8608823 - Flags: approval-mozilla-release?
Attachment #8608823 - Flags: approval-mozilla-beta?
Attachment #8608823 - Flags: approval-mozilla-aurora?
Attachment #8608823 - Flags: approval-mozilla-release? → approval-mozilla-release+
Comment on attachment 8608823 [details] [diff] [review]
Block vga driver

We can use the approvals already granted by Sylvestre on the previous patch.
Attachment #8608823 - Flags: approval-mozilla-beta?
Attachment #8608823 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/5f841d4a4a22
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Hi,

Do you have any idea when Firefox 38.0.5 will be the stable release? If that's in several weeks, is there any opportunity to backport the patch to the stable release?

As I have mentioned in the other bug, there are people complaining about this issue (in French): https://forums.mozfr.org/viewtopic.php?f=5&t=124416&p=790730#p790730

Florent
Flags: needinfo?(sledru)
(In reply to fayolle-florent from comment #37)
> Do you have any idea when Firefox 38.0.5 will be the stable release? 
June 2nd
Flags: needinfo?(sledru)
Nice then, thanks!

Florent
Release Note Request (optional, but appreciated)
[Why is this notable]: This is a problem that MANY Firefox users noticed after updating to 38.0.1
[Suggested wording]: Fixed slowdown in Hardware Acceleration on certain graphics hardware
[Links (documentation, blog post, etc)]:
relnote-firefox: --- → ?
Here's an alternative suggested wording that's more precise:
[Suggested wording]: Fixed graphics performance when using the built-in VGA driver on Windows 7
Added to the release notes with Jeff's proposal. Thanks!
I wonder if blocking WARP "hardware acceleration" in all cases is a good idea.
Actually, I just realized that this was caused by the enabling of WARP in the first place, so ignore.
https://www.youtube.com/watch?v=1RK3l6H0uDU&feature=youtu.be
Slow animation after version 38
The same (slow) situation in cases:
- safe mode
- when hardware acceleration disabled 
- after updating the graphic drivers
Video:
https://youtu.be/1RK3l6H0uDU
@Artem: you should consider updating to Firefox 38.0.5 that is now stable.

Florent
Unfortunately I'm using Firefox 38.0.5 and got this problen// In beta 39.0 too/
Here I created a post
https://bugzilla.mozilla.org/show_bug.cgi?id=1171966
Hi,

any idea when this fix will be released in an ESR release?
With 38.1.0esr, published the same day as 39. June 30th.
Disabling WARP on Windows 7 with built-in VGA driver wasn't sufficient, apparently.

Firefox 41 will disable WARP on all Windows 7 systems:
https://bugzilla.mozilla.org/show_bug.cgi?id=1179504
You need to log in before you can comment on or make changes to this bug.