1320531 - Dragging window causes high CPU load / FPS rate on versions greater than 46.0.1

Status: RESOLVED FIXED

(Firefox :: Untriaged, defect)

Description

[Andi Brot]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393

Steps to reproduce:

Dragging the browser window.
System specs:
Windows 10 64bit
intel i5 2500k
Asus GTX1060 
Video driver: Nvidia 375.70



Actual results:

Versions higher than 46.0.1 show high CPU load and high FPS rates when dragging the browser window. Version 50 even hung after a few quick moves. 
I used about:config > layers.acceleration.draw-fps=true to check it. When dragging the left most number rises to 150+. Middle and right numbers are stable 0 and 100. Version 46 and below do not show this.


Expected results:

No high CPU load and no increase in FPS while dragging the browser window.

Comment 1

[u554753]

Hi,

Thanks for reporting the issue. Are you running any addons? Can you paste your info from about:support?

Comment 2

[Andi Brot]

Hi, thanks for taking care of the issue.

For completeness: I tried safe mode and creating new profiles as well.

Here are about:support and about:plugins

Application Basics
-------------------------------------------
Name 	Firefox
Version 	50.0
Build ID 	20161104212021
Update History 	
Update Channel 	release
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
OS 	Windows_NT 10.0
Profile Folder 	
Enabled Plugins 	about:plugins
Build Configuration 	about:buildconfig
Memory Use 	about:memory
Performance 	about:performance
Registered Service Workers 	about:serviceworkers
Multiprocess Windows 	0/1 (Disabled by add-ons)
Safe Mode 	false
Profiles 	about:profiles
Crash Reports for the Last 3 Days
Report ID 	Submitted


All Crash Reports
-------------------------------------------
Extensions
Name 	Version 	Enabled 	ID
Application Update Service Helper	1.0	true	[e-mail]
Multi-process staged rollout	1.5	true	[e-mail]
NoScript	2.9.5.2	true	{73a6fe31-595d-460b-a920-fcc0f8843232}
Pocket	1.0.5	true	[e-mail]
QuickJS	1.3.1-signed.1-signed	true	{bb65e674-b194-4b6e-8033-5fa0afe3a198}
Web Compat	1.0	true	[e-mail]
Graphics
Features
Compositing	Direct3D 11
Asynchronous Pan/Zoom	none
WebGL Renderer	Google Inc. -- ANGLE (NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0)
WebGL2 Renderer	(no info)
Hardware H264 Decoding	Yes; Using D3D11 API
Audio Backend	wasapi
Direct2D	true
DirectWrite	true (10.0.14393.351)
GPU #1
Active	Yes
Description	NVIDIA GeForce GTX 1060 6GB
Vendor ID	0x10de
Device ID	0x1c03
Driver Version	21.21.13.7570
Driver Date	10-25-2016
Drivers	C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2umx C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvd3dum,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2um
Subsys ID	00000000
RAM	6144
Diagnostics
ClearType Parameters	Gamma: 2,2 Pixel Structure: RGB
AzureCanvasAccelerated	0
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
ClearType Parameters	Gamma: 2,2 Pixel Structure: RGB
Decision Log
D3D9_COMPOSITING	
disabled by default: Disabled by default
Important Modified Preferences
Name 	Value accessibility.typeaheadfind.flashBar	0
browser.cache.disk.capacity	358400
browser.cache.disk.filesystem_reported	1
browser.cache.disk.hashstats_reported	1
browser.cache.disk.smart_size.first_run	false
browser.cache.disk.smart_size.use_old_max	false
browser.cache.frecency_experiment	4
browser.download.importedFromSqlite	true
browser.places.smartBookmarksVersion	8
browser.sessionstore.interval	360000
browser.sessionstore.upgradeBackup.latestBuildID	20161104212021
browser.startup.homepage_override.buildID	20161104212021
browser.startup.homepage_override.mstone	50.0
browser.tabs.remote.autostart.2	true
browser.tabs.warnOnClose	false
browser.urlbar.daysBeforeHidingSuggestionsPrompt	3
browser.urlbar.lastSuggestionsPromptDate	20161203
dom.apps.reset-permissions	true
dom.mozApps.used	true
extensions.lastAppVersion	50.0
gfx.crash-guard.d3d11layers.appVersion	50.0
gfx.crash-guard.d3d11layers.deviceID	0x1c03
gfx.crash-guard.d3d11layers.driverVersion	21.21.13.7570
gfx.crash-guard.d3d11layers.feature-d2d	true
gfx.crash-guard.d3d11layers.feature-d3d11	true
gfx.crash-guard.status.d3d11layers	2
gfx.crash-guard.status.d3d11video	2
gfx.crash-guard.status.d3d9video	2
gfx.direct3d.last_used_feature_level_idx	0
layers.acceleration.draw-fps	true
media.gmp-eme-adobe.abi	x86-msvc-x64
media.gmp-eme-adobe.enabled	false
media.gmp-eme-adobe.lastUpdate	1480149485
media.gmp-eme-adobe.version	17
media.gmp-gmpopenh264.abi	x86_64-msvc-x64
media.gmp-gmpopenh264.lastUpdate	1480751106
media.gmp-gmpopenh264.version	1.6
media.gmp-manager.buildID	20161104212021
media.gmp-manager.lastCheck	1480751106
media.gmp-widevinecdm.abi	x86_64-msvc-x64
media.gmp-widevinecdm.lastUpdate	1480751108
media.gmp-widevinecdm.version	1.4.8.903
media.gmp.storage.version.observed	1
media.hardware-video-decoding.failed	false
network.cookie.prefsMigrated	true
network.predictor.cleaned-up	true
places.database.lastMaintenance	1480152111
places.history.expiration.transient_current_max_pages	59862
plugin.disable_full_page_plugin_for_types	application/pdf
plugin.importedState	true
plugin.state.npbattlelog	0
plugin.state.npctrl	0
plugin.state.npwacomtabletplugin	0
privacy.sanitize.migrateClearSavedPwdsOnExit	true
security.sandbox.content.tempDirSuffix	{db2fe1c7-5b33-4f54-b4cd-ef3c014f622b}
storage.vacuum.last.index	1
storage.vacuum.last.places.sqlite	1480152111
ui.osk.debug.keyboardDisplayReason	IKPOS: Touch screen not found.


Important Locked Preferences
-------------------------------------------
Places Database
Integrity 	
JavaScript
Incremental GC 	true
Accessibility
Activated 	false
Prevent Accessibility 	0
Library Versions
	Expected minimum version	Version in use
NSPR	4.12	4.12
NSS	3.26.2	3.26.2
NSSSMIME	3.26.2	3.26.2
NSSSSL	3.26.2	3.26.2
NSSUTIL	3.26.2	3.26.2
Experimental Features
Name 	ID 	Description 	Active 	End Date 	Homepage 	Branch
Sandbox
Content Process Sandbox Level	1

____________________________________________

Plugins
--------------------------------------------
Installed plugins
OpenH264 Video Codec provided by Cisco Systems, Inc.

    File: 1.6
    Path: C:\Users\Toni\AppData\Roaming\Mozilla\Firefox\Profiles\7wjh2i1h.default\gmp-gmpopenh264\1.6
    Version: 1.6
    State: Enabled
    This plugin is automatically installed by Mozilla to comply with the WebRTC specification and to enable WebRTC calls with devices that require the H.264 video codec. Visit http://www.openh264.org/ to view the codec source code and learn more about the implementation.

MIME Type	Description	Suffixes
Primetime Content Decryption Module provided by Adobe Systems, Incorporated

    File: 17
    Path: C:\Users\Toni\AppData\Roaming\Mozilla\Firefox\Profiles\7wjh2i1h.default\gmp-eme-adobe\17
    Version: 17
    State: Disabled
    Play back protected web video.

MIME Type	Description	Suffixes
Widevine Content Decryption Module provided by Google Inc.

    File: 1.4.8.903
    Path: C:\Users\Toni\AppData\Roaming\Mozilla\Firefox\Profiles\7wjh2i1h.default\gmp-widevinecdm\1.4.8.903
    Version: 1.4.8.903
    State: Enabled
    Play back protected web video.

MIME Type	Description	Suffixes
Silverlight Plug-In

    File: npctrl.dll
    Path: C:\Program Files\Microsoft Silverlight\5.1.50901.0\npctrl.dll
    Version: 5.1.50901.0
    State: Disabled
    5.1.50901.0

MIME Type	Description	Suffixes
application/x-silverlight	npctrl	scr
application/x-silverlight-2

Comment 3

[u554753]

Thanks for providing the information. However, I can't seem to reproduce the issue. Can you use the Gecko Profiler to send us a snapshot of your profile? We can use this information to better understand what's going on.

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Comment 4

[Andi Brot]

(In reply to Grover Wimberly IV [:Grover-QA] from comment #3)
> Thanks for providing the information. However, I can't seem to reproduce the
> issue. Can you use the Gecko Profiler to send us a snapshot of your profile?
> We can use this information to better understand what's going on.
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Profiling_with_the_Built-in_Profiler

Thanks for answering. Sorry for the delay. 

I did two profiles. One with a problematic version (50.1.0) and one with trouble free 46.0.1.
During recording I dragged the browser window three times with breaks in between.

Firefox 50.1.0
https://cleopatra.io/#report=e26c524288a5ae5d572a1670479d9f27c4d8ce4f

Firefox 46.0.1
https://cleopatra.io/#report=0e6fcfd6a7401cf95dd8e9f4c54604139b4ecdf2

Comment 5

[u554753]

Adding NeedInfo - Can you take a look at Comment 4?

Comment 6

[Mike Conley (:mconley) (:⚙️) (Catching up on needinfos)]

The profile indicates that we're spending quite a lot of time inside TabsInTitlebar.handleEvent in the problematic build 948 samples, to be precise. In the good build, we never even enter that function.

A quick glance at the source shows that the only reason we'd be calling anything from within TabsInTitlebar.handleEvent is if the event was of type "resolutionchange".

When you ran this test, were you dragging the window between monitors of different resolutions?

Comment 7

[Andi Brot]

No, just one single monitor. Tried it with different monitor and different resolution. No change.

BTW Do I have to do someting relating to the needinfo requested?

Comment 8

[Mike Conley (:mconley) (:⚙️) (Catching up on needinfos)]

(In reply to Andi Brot from comment #7)
> No, just one single monitor. Tried it with different monitor and different
> resolution. No change.
> 
> BTW Do I have to do someting relating to the needinfo requested?

Very interesting - thanks Andi. You have the option of requesting needinfo? from someone if you have a question and you want to queue it for somebody, but I've seen your comment, and we're moving forward here, so it's okay. :)

Hey jkew - I seem to recall you working on some scaling stuff... do you know why we might have started firing more resolutionchange events since v 46?

Comment 9

[Andi Brot]

If I may chip in here.

There are two bug filings that look like the source for this.

Investigate overlap between window controls and tabs in mixed-dpi 2+-screen situations
https://bugzilla.mozilla.org/show_bug.cgi?id=1256731

and it's potential offspring

TabsInTitleBar._update should group measurements and style changes to avoid unnecessary reflows
https://bugzilla.mozilla.org/show_bug.cgi?id=890105

Both filings are assigned to [e-mail]

Comment 10

[Andi Brot]

51.0.1 is next to unusable. 

I barely can drag the browser window.
CPU usage is good now, but the window movement stutters and ends in hanging.

I did a profile:
https://cleopatra.io/#report=56c4bf8ef0473896247f149c66b10c350ddfcba3&selection=0,1,213,126

Comment 11

[Andi Brot]

Did some further testing.
Disabled 2D acceleration. CPU is very high again.
With 2D acceleration GP usage is high. Should be next to zero.

Comment 12

[Jonathan Kew (:jfkthame)]

(In reply to Mike Conley (:mconley) - Dealing with review and needinfo queue from comment #8)
> Hey jkew - I seem to recall you working on some scaling stuff... do you know
> why we might have started firing more resolutionchange events since v 46?

Previously, there was no such event, IIRC.

In bug 1264193 (landed for v47), we started calling the ChangedDPI() method in our Windows widget code whenever a window moves during a drag, because Windows sometimes seems to drop the system event that we depend on to tell us about a resolution change. That was supposed to be OK, because the nsPresContext and nsXULWindow methods it ends up calling will detect if nothing significant has actually changed, and return without doing lots of redundant work.

However, in bug 1256731 (also v47) we also made the widget code send a "resolutionchanged" event when handling ChangedDPI(), and made the TabsInTitlebar code listen for it. This was needed so that we can recompute title bar dimensions, etc., properly for a changed configuration. And TabsInTitlebar.handleEvent responds to that by calling _update().

So I guess the immediate root of the problem here is that during window dragging, we repeatedly fire resolutionchange events (because we can't rely on Windows notifying us when it's really needed); that results in repeatedly calling TabsInTitlebar._update(), and that is expensive and drags the browser to its knees.

I wonder, though, why this is a problem for Andi but doesn't seem to be affecting everyone else similarly? Those resolutionchanged events should be firing on every Windows system from 8.1 onwards (everywhere WinUtils::IsPerMonitorDPIAware() returns true), but most people can still drag windows around without difficulty.

Comment 13

[Mike Conley (:mconley) (:⚙️) (Catching up on needinfos)]

Could it be related to whether HWA is enabled? See bug 1334807 comment 2.

Comment 14

[Jonathan Kew (:jfkthame)]

I tried switching HWA on/off (and also e10s on/off) locally, but it didn't seem to make much difference.

I notice that on my local Win10 system with layers.acceleration.draw-fps, I do see an unexpectedly high frame rate while dragging the window, but everything remains responsive and there's no noticeable impact on the UI. (I do get occasional stutters, but I put that down to the fact that I'm using a debug build that logs stuff to the terminal window, etc., so it's never as smooth as a release build would be.)

Anyhow, I do think there's an issue here we should try to address; although I'm not seeing a lot of ill effects from the elevated frame rate, it indicates an inefficiency. And if we're compositing too often, even without re-rendering the content (which we don't do, AFAICT), maybe this becomes a serious burden on less-powerful systems, or if the system is generally busier.

Comment 15

[Jonathan Kew (:jfkthame)]

Attachment: Check whether DPI appears to have changed before calling ChangedDPI + ResetLayout at the end of a window drag

This should fix the elevated-FPS issue here, by ensuring that we don't call ResetLayout continually during a window drag, but only if the resolution actually changes. We'll need to watch for any recurrence of bug 1264193 after doing this, but AFAICT in local testing it doesn't seem to be a problem.

Comment 16

[Jonathan Kew (:jfkthame)]

Andi, there is a test build of Firefox Nightly with this patch at https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-118f8f88555c2303e749bbb5b09b759b8b41317e/try-win32/ (available as either an installer .exe, or a .zip archive). If you could give it a try and confirm that it fixes the issue you're seeing, that would be awesome. Thanks!

Comment 17

[Andi Brot]

The Nightly works perfectly. 
I tried HWA on/off. CPU and GPU loads are normal now.

I did another profile:
https://cleopatra.io/#report=81f2ee1c2042b76f87523b2f213352439c802966&selection=0,1,2,3,4,5

1e³ kudos!

Comment 18

[Jonathan Kew (:jfkthame)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0159e55566c4c4b341ca6fc368b27a49f5c5a5a8
Bug 1320531 - Check whether DPI appears to have changed before calling ChangedDPI + ResetLayout while dragging windows. r=emk

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0159e55566c4
Check whether DPI appears to have changed before calling ChangedDPI + ResetLayout while dragging windows. r=emk

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/0159e55566c4

Comment 21

[Jonathan Kew (:jfkthame)]

Bogdan, the fix here touches the patch we landed back in bug 1264193, so if you could be alert for any regression in that behavior (broken layout after dragging a window between monitors with different dpi) that would be great - thanks!

Comment 22

[Fil Sapia]

Can confirm that this is issue which returns most of the time I enable hardware acceleration. Have exact same addons and sync account on laptop and work PC and do not experience this issue on those.

-H/W-
OS: Windows 10 Pro (x64) 10.0.14393
CPU: Intel i7 3770K 3.4GHz (OC to 4.2GHz)
MOBO: ASRock Z77 Pro4
GPU: NVIDIA GTX 1080 8GB (OC)
DISPLAY: LG Ultrawide 2560 x 1080 @60Hz
MEMORY: 4x4GB Corsair 1600MHz (OC to 1800MHz)
STORAGE: Samsung 840 Pro 512GB SSD
Hitachi 2TB 7200RPM HDD

Comment 23

[Jonathan Kew (:jfkthame)]

(In reply to Fil Sapia from comment #22)
> Can confirm that this is issue which returns most of the time I enable
> hardware acceleration.

With what version of Firefox?

Comment 24

[Fil Sapia]

(In reply to Jonathan Kew (:jfkthame) from comment #23)
> (In reply to Fil Sapia from comment #22)
> > Can confirm that this is issue which returns most of the time I enable
> > hardware acceleration.
> 
> With what version of Firefox?

I'm on 51.0.1 (32-bit).

Comment 25

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

(In reply to Jonathan Kew (:jfkthame) from comment #21)
> Bogdan, the fix here touches the patch we landed back in bug 1264193, so if
> you could be alert for any regression in that behavior (broken layout after
> dragging a window between monitors with different dpi) that would be great -
> thanks!

Sure Jonathan, I'll add this to my to do list! Leaving the needinfo on me just as a reminder.

Comment 26

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

I just finished running a Smoke test using latest Nightly on W10, W8.1 and MacBook Pro with retina display and I ran into a new issue bug 1344780 which regressed from this fix. No other new issues were discovered, only known old bugs.