Closed Bug 1320531 Opened 4 years ago Closed 4 years ago
Dragging window causes high CPU load / FPS rate on versions greater than 46
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.
Has Regression Range: --- → yes
Summary: Dragging window causes high CPU load / FPS rate. → Dragging window causes high CPU load / FPS rate on versions greater than 46.0.1
Hi, Thanks for reporting the issue. Are you running any addons? Can you paste your info from about:support?
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
(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
Adding NeedInfo - Can you take a look at Comment 4?
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?
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?
(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?
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 firstname.lastname@example.org
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
Did some further testing. Disabled 2D acceleration. CPU is very high again. With 2D acceleration GP usage is high. Should be next to zero.
(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.
Could it be related to whether HWA is enabled? See bug 1334807 comment 2.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Attachment #8832203 - Flags: review?(VYV03354)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Andi, there is a test build of Firefox Nightly with this patch at https://email@example.com/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!
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!
Attachment #8832203 - Flags: review?(VYV03354) → review+
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
Pushed by firstname.lastname@example.org: 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
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!
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
(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?
(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).
(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.
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.
You need to log in before you can comment on or make changes to this bug.