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

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?

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

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)

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.

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

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

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.

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.

The go to build of 38.0.5 RC is today (starting in a few hours). Do you expect to have a fix today?

Yessir.

I have a patch written, that I'm just building now.

\o/

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.

This a tested version. The only change was to make gfxCriticalError not assert.

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.

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.

Comment on attachment 8608823 [details] [diff] [review] Block vga driver We can use the approvals already granted by Sylvestre on the previous patch.

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

(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

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)]:

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