1924932 - Excessive Windows DWM usage when screen is locked and display enters standby

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[Robbie Khan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

1: Prepare aloop-script in Powershell to poll every 10 seconds a list of processes using CPU cycles, the script:
$Counter = "\Process(*)% Processor Time"
$Interval = 10 # Number of seconds between loops

while ($true) {
$Procs = Get-Counter -Counter $Counter
$Procs.Timestamp
$Procs.CounterSamples |
Where-Object -Property CookedValue -GT 0 |
Sort-Object -Property CookedValue -Descending |
Format-Table -Property InstanceName, @{ Label='CPU'; Expression={$_.CookedValue/100}; FormatString='P' } -AutoSize

Start-Sleep $Interval

}

2: Windows is locked and Firefox is open or minimised to taskbar.

3: Windows automatically puts the display to sleep/standby as is normal for the lockscreen after 1 minute of sitting on the lockscreen

4: Wait a further minute after display goes to sleep

5: Wake the PC and unlock Windows

6: Stop the script from looping (CTRL+C)

Actual results:

1: Whilst the display is asleep in the lockscreen, the CPU fans can be heard ramping up slightly

2: The Powershell script's output shows that during this time, Windows DWM was using excessive CPU time, and CPU core temperatures increase as a result:
InstanceName CPU

---

_total 2,006.89%
idle 1,875.67%
dwm 118.87%
hwinfo64 4.63%
system 4.63%
sabnzbd 1.54%
firefox 1.54%

3: The GPU core usage spikes as well during this as seen in GPU monitoring apps such as HWINFO64.

4: The excessive DWM use stops as soon as the display wakes back up on the lock screen.

5: This happens in any mode within Firefox, with only a=n incognito window open, with a new profile, with add-ons disabled and so on. As long as Firefox is open, the issue is observed, and only once the display enters standby.

Expected results:

No excess CPU use caused by DWM should be seen at all.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Robbie Khan]

Reference link on r/firefox where additional details exist:

https://www.reddit.com/r/firefox/comments/1g4qry3/ive_found_a_bug_that_causes_windows_dwm_to_use/

Comment 3

[Ed]

Just noting that at least for me, a backslash is missing in line one of the code:

$Counter = "\Process(*)% Processor Time" should be $Counter = "\Process(*)\% Processor Time" .

Comment 4

[Paul]

I can reproduce this bug as well. Win11 24H2 (RTX 4090 + 5800X3D). If firefox is running, as soon as monitors go to sleep dwm.exe cpu increases. As soon as monitors wake up it goes back down. Locking the PC is not required. Minimizing firefox prior to sleep sometimes avoids the bug (& sometimes does not). I tried disabling Hardware Accelerated GPU Scheduler and rebooting but it didn't help.

Comment 5

[Yannis Juglaret [:yannis]]

Attachment: windowsperformancerecorder.png

Hi Robbie & Paul. Thank you very much for the report. Could you try to follow the steps below which should help in identifying what DWM is doing?

1. Install the Windows Performance Toolkit from the Windows ADK for your version of Windows. You can safely unselect the installation of other features.
2. Close as many open applications as possible to avoid noise in collecting the data.
3. Open Firefox and prepare to reproduce the issue as if you were going to use the script, though don't reproduce it yet.
4. Instead of launching the script, open Windows Performance Recorder and configure it exactly as shown in attachment (in particular, make sure to use Detail level: Verbose). Click Start.
5. Reproduce the issue as you would if the script were now running.
6. Instead of stopping the script, click Save in Windows Performance Recorder. Click Compress and then Save again.
7. Share the ETL file recorded by Windows Performance Recorder with me, privately, by email at [e-mail]. You will likely need to use a cloud storage service like Microsoft OneDrive or Google Drive due to the size of the file.

Thanks!

Comment 6

[Robbie Khan]

(In reply to Yannis Juglaret [:yannis] from comment #5)

Created attachment 9440975 [details]
windowsperformancerecorder.png

Hi Robbie & Paul. Thank you very much for the report. Could you try to follow the steps below which should help in identifying what DWM is doing?

1. Install the Windows Performance Toolkit from the Windows ADK for your version of Windows. You can safely unselect the installation of other features.
2. Close as many open applications as possible to avoid noise in collecting the data.
3. Open Firefox and prepare to reproduce the issue as if you were going to use the script, though don't reproduce it yet.
4. Instead of launching the script, open Windows Performance Recorder and configure it exactly as shown in attachment (in particular, make sure to use Detail level: Verbose). Click Start.
5. Reproduce the issue as you would if the script were now running.
6. Instead of stopping the script, click Save in Windows Performance Recorder. Click Compress and then Save again.
7. Share the ETL file recorded by Windows Performance Recorder with me, privately, by email at [e-mail]. You will likely need to use a cloud storage service like Microsoft OneDrive or Google Drive due to the size of the file.

Thanks!

Hi,

I have done two tests using this, the first run was with Firefox open and minimised to taskbar as per my original post, and the second run with Firefox open fully and then Windows was locked and allowed to go to display sleep as per OP.

I have emailed you both saved performance monitor outputs.

Many thanks

Comment 7

[Yannis Juglaret [:yannis]]

Attachment: UIforETW.png

Thanks a lot for your reactivity! I confirm the bug based on what I'm seeing.

There is indeed a significant, long DWM spike in the "minimized" recording that seems to only stop when the screen gets unlocked. This does not seem to happen in the "open" recording -- as far as I can tell the issue didn't reproduce this time (but that's OK).

The spike indeed correlates with the moment when the csrss.exe process's power notification thread wakes up and (I presume) notifies everyone that we have/will shut down the screen, resulting in UsoSvc waking up to ProcessUserAwaySignal and then the start of MoUsoCoreWorker.exe, then OfficeC2RClient.exe, and the WaaSMedicSvc service, etc. I presume those are because Windows thinks that screen power off is a good time to do update-related things without impacting the user's workflow. The detail of the events I listed doesn't matter here -- what's important is that the same sequence happens on my own machines when the screen goes off, except for the DWM spike, confirming that the spike is unexpected.

One source of uncertainty is the presence of activity from logioptionsplus_agent.exe near the start of the spike -- presumably reacting to the screen turning off too. It would be worth trying to disable this agent and confirm that the bug is still present (i.e. confirm that the bug is not caused by a weird interaction between Firefox and this agent).

It would also be interesting to know what Firefox is doing during this time, because I do see some limited activity of Firefox processes during the DWM spike. To do that, you can record a performance profile while reproducing the issue (instead of using WPR). I would recommend using the Graphics preset here (although the Debug preset could also be interesting -- if you have the time). Feel free to use your script while recording to confirm that the issue occurred, as this should not impact the recording.

Finally, maybe we can get more clues about DWM's behavior by monitoring it more closely. You could do that with UIforETW (instead of WPR) as follows:

• download and extract etwpackage1.59.zip;
• navigate to the etwpackage, bin and execute UIforETW.exe;
• configure as shown in the attachment, where the contents for Extra user mode providers is Microsoft-Windows-Dwm-Api+Microsoft-Windows-Dwm-Core+Microsoft-Windows-Dwm-Dwm+Microsoft-Windows-Dwm-Redir+Microsoft-Windows-Dwm-Udwm+Microsoft-Windows-Dwm-Compositor;
• click OK in the Settings window;
• click Start Tracing (feel free to also start your script at this point);
• if UIforETW later refuses to start, try removing +Microsoft-Windows-Dwm-Compositor in the list above, as I'm not sure that this provider is available on Windows 10;
• reproduce the issue;
• click Save Trace Buffers (and feel free to stop your script and check the output);
• under Traces, use right click, Browse folder to find the produced ETL file;
• share the ETL file with me privately again.

Thanks for any further info you can provide -- I realize that I'm asking a lot here.

Comment 8

[Robbie Khan]

(In reply to Yannis Juglaret [:yannis] from comment #7)

Created attachment 9441096 [details]
UIforETW.png

Thanks a lot for your reactivity! I confirm the bug based on what I'm seeing.

There is indeed a significant, long DWM spike in the "minimized" recording that seems to only stop when the screen gets unlocked. This does not seem to happen in the "open" recording -- as far as I can tell the issue didn't reproduce this time (but that's OK).

The spike indeed correlates with the moment when the csrss.exe process's power notification thread wakes up and (I presume) notifies everyone that we have/will shut down the screen, resulting in UsoSvc waking up to ProcessUserAwaySignal and then the start of MoUsoCoreWorker.exe, then OfficeC2RClient.exe, and the WaaSMedicSvc service, etc. I presume those are because Windows thinks that screen power off is a good time to do update-related things without impacting the user's workflow. The detail of the events I listed doesn't matter here -- what's important is that the same sequence happens on my own machines when the screen goes off, except for the DWM spike, confirming that the spike is unexpected.

One source of uncertainty is the presence of activity from logioptionsplus_agent.exe near the start of the spike -- presumably reacting to the screen turning off too. It would be worth trying to disable this agent and confirm that the bug is still present (i.e. confirm that the bug is not caused by a weird interaction between Firefox and this agent).

It would also be interesting to know what Firefox is doing during this time, because I do see some limited activity of Firefox processes during the DWM spike. To do that, you can record a performance profile while reproducing the issue (instead of using WPR). I would recommend using the Graphics preset here (although the Debug preset could also be interesting -- if you have the time). Feel free to use your script while recording to confirm that the issue occurred, as this should not impact the recording.

Finally, maybe we can get more clues about DWM's behavior by monitoring it more closely. You could do that with UIforETW (instead of WPR) as follows:

• download and extract etwpackage1.59.zip;
• navigate to the etwpackage, bin and execute UIforETW.exe;
• configure as shown in the attachment, where the contents for Extra user mode providers is Microsoft-Windows-Dwm-Api+Microsoft-Windows-Dwm-Core+Microsoft-Windows-Dwm-Dwm+Microsoft-Windows-Dwm-Redir+Microsoft-Windows-Dwm-Udwm+Microsoft-Windows-Dwm-Compositor;
• click OK in the Settings window;
• click Start Tracing (feel free to also start your script at this point);
• if UIforETW later refuses to start, try removing +Microsoft-Windows-Dwm-Compositor in the list above, as I'm not sure that this provider is available on Windows 10;
• reproduce the issue;
• click Save Trace Buffers (and feel free to stop your script and check the output);
• under Traces, use right click, Browse folder to find the produced ETL file;
• share the ETL file with me privately again.

Thanks for any further info you can provide -- I realize that I'm asking a lot here.

Cheers for these details, rather interesting for sure.

So logioptionsplus is for my Logitech mouse and has various profiles for apps to map custom button functions when in those apps, Firefox is one of those profiles. I killed the exe and its supporting services then minimised Firefox and locked the OS. Once screen goes to sleep I could hear the CPU fan ramping up the RPM as before so it does not seem that Logitech's software is a contributing factor to this.

I ran the profiler with the graphics preset and this was the result:
https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=0wx8&hiddenGlobalTracks=1whjlnorx1wx5&hiddenLocalTracksByPid=15788-0~22044-02wyt&thread=l&v=10

I then ran it again using debug:
https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=0wx9&hiddenGlobalTracks=1wjmorwx3x5x7x8&hiddenLocalTracksByPid=15788-0w46wx4x6wz6z8wzd~29052-0wx4~31536-0wx6~18500-0wx6~23524-0wn~4620-0wn~6712-0wx5~34796-0wo~34632-0wu~40824-0w6~28624-0w6~23840-0wx1~27280-0wv~21404-0wx6~14736-0wx0~36976-0w6~16800-0w6~38632-0w6~24684-0w6~15572-0wu~33004-0wqtwx8~22044-0w24wz7~36528-0wx2~32184-0wx1x3wx6~11820-0wv~16032-0wvx1wx4~43964-1wv~17712-0wv~26824-0wv~39160-0wu~15000-0wu~32212-0wu~38928-0wv~40028-0wx1~26832-0wx1~14836-0wx2~19736-0wx0~25256-0wv~31960-0wvx1wx4~7048-0wx2~16636-0wx6~21000-0wx0x2wx5&thread=M0&v=10

The debug run took longer to process and has a much bigger performance impact as the CPU is constantly running at around 19% utilised when I click the record button, but even still I was able to hear the CPU fan ramp up the RPMs again once the screen goes to sleep.

Finally, I ran the tracer and didn't need to run my script as it's easy enough to hear the CPU fan ramping up to signify the same conditions in effect so have saved the produced file and uploaded it into the same Google Drive folder link I emailed you previous, please find it in there labelled 'UIforETW_2024-12-02_23-44-21_Robbie Khan.etl'.

Also, as you have seen from the previous recording, it is clear that the issue only happens when Firefox is minimised to the taskbar, if the browser is open and not minimised, and I then lock Windows, the issue does not present itself.

Comment 9

[Itiel]

Note that urls you've shared are private and can't be seen by others, you need to share them using the Share button (top right corner if I recall correctly).

Comment 10

[Robbie Khan]

(In reply to Itiel from comment #9)

Note that urls you've shared are private and can't be seen by others, you need to share them using the Share button (top right corner if I recall correctly).

Ah yes, corrected. New links below.

Graphics profile:
https://share.firefox.dev/3Zl7Lo5

Debug profile:
https://share.firefox.dev/3ZxKb8N

Comment 11

[Yannis Juglaret [:yannis]]

Attachment: dwm-markers.png

Thanks a lot! Attached is the DWM-related events captured by UIforETW at the start of the spike (we start to see a repeating pattern that later goes on). dwm.exe is in green (reporting most events as they occur internally), firefox.exe is in light green (reporting its use of the DwmFlush and DwmGetCompositionTimingInfo APIs), logioptionsplus_agent.exe is in cyan (reporting its use of the DwmDxGetWindowSharedSurface API).

Is it expected that logioptionsplus_agent.exe is still present in this recording? Could it have been restarted automatically after you killed it? This view shows that it has direct interaction with DWM, so it would be good to completely eliminate it during the investigation if possible.

Ignoring logioptionsplus_agent.exe for the moment, we can see a cycle take place where each time that DWM appears to be done dealing with a DwmFlush, firefox.exe immediately issues a new call to DwmFlush (approximately every 4ms), resulting in continuous CPU usage from DWM. This would be caused by the VSync thread, which sampling catches running with the following call stacks (numbers below are from the WPR "minimized" recording during the whole DWM spike):

[Root] (157)
  |- ntdll.dll!RtlUserThreadStart (153)
  |    mozglue.dll!patched_BaseThreadInitThunk (153)
  |    kernel32.dll!BaseThreadInitThunk (153)
  |    xul.dll!`anonymous namespace'::ThreadFunc (153)
  |    xul.dll!base::Thread::ThreadMain (153)
  |    xul.dll!MessageLoop::RunHandler (153)
  |    xul.dll!base::MessagePumpDefault::Run (153)
  |    xul.dll!MessageLoop::DoWork (153)
  |    xul.dll!mozilla::detail::RunnableMethodImpl<nsCOMPtr<nsIThreadPool>,nsresult (nsIThreadPool::*)(),1,0>::Run (153)
  |    xul.dll!D3DVsyncSource::VBlankLoop (153)
  |    |- dwmapi.dll!DwmFlush (86)
  |    |- xul.dll!mozilla::gfx::VsyncSource::NotifyVsync (54)
  |    |    |- xul.dll!mozilla::dom::VsyncParent::NotifyVsync (50)
  |    |    |    |- xul.dll!nsThread::DispatchToQueue (49)
  |    |    |    |- xul.dll!nsThreadManager::GetCurrentThread (1)
  |    |    |- mozglue.dll!je_free (1)
  |    |    |- xul.dll!nsTArray_base<nsTArrayInfallibleAllocator,nsTArray_RelocateUsingMemutils>::EnsureCapacityImpl<nsTArrayInfallibleAllocator> (1)
  |    |    |- ?!? (1)
  |    |    |- xul.dll!mozilla::gfx::VsyncSource::NotifyVsync<itself> (1)
  |    |- dxgi.dll!CDXGIOutput::WaitForVBlank (5)
  |    |    win32u.dll!NtGdiDdDDIWaitForVerticalBlankEvent (5)
  |    |- xul.dll!D3DVsyncSource::VBlankLoop<itself> (1)
  |    |- xul.dll!D3DVsyncSource::GetVBlankTime (3)
  |    |    dwmapi.dll!DwmGetCompositionTimingInfo (3)
  |    |    dwmapi.dll!DwmpGetCompositionTimingInfoEx (3)
  |    |    dcomp.dll!DCompositionGetFrameStatistics (3)
  |    |    |- win32u.dll!NtDCompositionGetFrameStatistics (2)
  |    |    |- dcomp.dll!DCompositionGetFrameStatistics<itself> (1)
  |    |- user32.dll!MonitorFromWindow (2)
  |- ntoskrnl.exe!KiSystemServiceCopyEnd (4)
  |    |- ntoskrnl.exe!NtAlpcSendWaitReceivePort (3)
  |    |- ntoskrnl.exe!NtAlertThreadByThreadIdEx (1)

Our D3DVsyncSource::VBlankLoop code has a comment saying that "vblank might return instantly when running headless, monitor powering off, etc.", in this case we indeed set hr = E_FAIL; which will result in a call to DwmFlush, so since this happens in a loop this could explain the behavior. I'm not familiar enough with this code to know what part of what we're seeing here is weird and what part is normal behavior. Could you enlighten us in this regard, :mstange? (I'll share the links to the ETL files with you directly -- for some reason I didn't manage to convert them to the Firefox profiler format.)

Edit: For completeness, if I unzoom the cycle looks like this:

• firefox.exe issueing DwmFlush every 4 ms and DwmGetCompositionTimingInfo every 100 to 220 ms;
• logioptionsplus_agent.exe issueing DwmDxGetWindowSharedSurface every 14 to 20 ms.

Comment 12

[Yannis Juglaret [:yannis]]

Robbie, could you also attach the info from your about:support page? Thank you.

Comment 13

[Robbie Khan]

(In reply to Yannis Juglaret [:yannis] from comment #12)

Robbie, could you also attach the info from your about:support page? Thank you.

Sure please see here:
https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link
(I don't see an option in the message box here to attach so Gdrive link instead)

Comment 14

[Robbie Khan]

(In reply to Yannis Juglaret [:yannis] from comment #11)

Created attachment 9441314 [details]
dwm-markers.png

Thanks a lot! Attached is the DWM-related events captured by UIforETW at the start of the spike (we start to see a repeating pattern that later goes on). dwm.exe is in green (reporting most events as they occur internally), firefox.exe is in light green (reporting its use of the DwmFlush and DwmGetCompositionTimingInfo APIs), logioptionsplus_agent.exe is in cyan (reporting its use of the DwmDxGetWindowSharedSurface API).

Is it expected that logioptionsplus_agent.exe is still present in this recording? Could it have been restarted automatically after you killed it? This view shows that it has direct interaction with DWM, so it would be good to completely eliminate it during the investigation if possible.

Ignoring logioptionsplus_agent.exe for the moment, we can see a cycle take place where each time that DWM appears to be done dealing with a DwmFlush, firefox.exe immediately issues a new call to DwmFlush (approximately every 4ms), resulting in continuous CPU usage from DWM. This would be caused by the VSync thread, which sampling catches running with the following call stacks (numbers below are from the WPR "minimized" recording during the whole DWM spike):

[Root] (157)
  |- ntdll.dll!RtlUserThreadStart (153)
  |    mozglue.dll!patched_BaseThreadInitThunk (153)
  |    kernel32.dll!BaseThreadInitThunk (153)
  |    xul.dll!`anonymous namespace'::ThreadFunc (153)
  |    xul.dll!base::Thread::ThreadMain (153)
  |    xul.dll!MessageLoop::RunHandler (153)
  |    xul.dll!base::MessagePumpDefault::Run (153)
  |    xul.dll!MessageLoop::DoWork (153)
  |    xul.dll!mozilla::detail::RunnableMethodImpl<nsCOMPtr<nsIThreadPool>,nsresult (nsIThreadPool::*)(),1,0>::Run (153)
  |    xul.dll!D3DVsyncSource::VBlankLoop (153)
  |    |- dwmapi.dll!DwmFlush (86)
  |    |- xul.dll!mozilla::gfx::VsyncSource::NotifyVsync (54)
  |    |    |- xul.dll!mozilla::dom::VsyncParent::NotifyVsync (50)
  |    |    |    |- xul.dll!nsThread::DispatchToQueue (49)
  |    |    |    |- xul.dll!nsThreadManager::GetCurrentThread (1)
  |    |    |- mozglue.dll!je_free (1)
  |    |    |- xul.dll!nsTArray_base<nsTArrayInfallibleAllocator,nsTArray_RelocateUsingMemutils>::EnsureCapacityImpl<nsTArrayInfallibleAllocator> (1)
  |    |    |- ?!? (1)
  |    |    |- xul.dll!mozilla::gfx::VsyncSource::NotifyVsync<itself> (1)
  |    |- dxgi.dll!CDXGIOutput::WaitForVBlank (5)
  |    |    win32u.dll!NtGdiDdDDIWaitForVerticalBlankEvent (5)
  |    |- xul.dll!D3DVsyncSource::VBlankLoop<itself> (1)
  |    |- xul.dll!D3DVsyncSource::GetVBlankTime (3)
  |    |    dwmapi.dll!DwmGetCompositionTimingInfo (3)
  |    |    dwmapi.dll!DwmpGetCompositionTimingInfoEx (3)
  |    |    dcomp.dll!DCompositionGetFrameStatistics (3)
  |    |    |- win32u.dll!NtDCompositionGetFrameStatistics (2)
  |    |    |- dcomp.dll!DCompositionGetFrameStatistics<itself> (1)
  |    |- user32.dll!MonitorFromWindow (2)
  |- ntoskrnl.exe!KiSystemServiceCopyEnd (4)
  |    |- ntoskrnl.exe!NtAlpcSendWaitReceivePort (3)
  |    |- ntoskrnl.exe!NtAlertThreadByThreadIdEx (1)

Our D3DVsyncSource::VBlankLoop code has a comment saying that "vblank might return instantly when running headless, monitor powering off, etc.", in this case we indeed set hr = E_FAIL; which will result in a call to DwmFlush, so since this happens in a loop this could explain the behavior. I'm not familiar enough with this code to know what part of what we're seeing here is weird and what part is normal behavior. Could you enlighten us in this regard, :mstange? (I'll share the links to the ETL files with you directly -- for some reason I didn't manage to convert them to the Firefox profiler format.)

Edit: For completeness, if I unzoom the cycle looks like this:

• firefox.exe issueing DwmFlush every 4 ms and DwmGetCompositionTimingInfo every 100 to 220 ms;
• logioptionsplus_agent.exe issueing DwmDxGetWindowSharedSurface every 14 to 20 ms.

I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case.

Comment 15

[Yannis Juglaret [:yannis]]

(In reply to Robbie Khan from comment #13)

Sure please see here:
https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link
(I don't see an option in the message box here to attach so Gdrive link instead)

Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian).

Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox triggers the DwmFlush at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz?

Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profiles you recorded, in the Privileged Content process's markers. The accessibility notifications appear there as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed? For this test, about:support should show (possibly only after a restart of Firefox):

Accessibility
-------------

Activated: false
Prevent Accessibility: 0
Accessibility Instantiator:

(In reply to Robbie Khan from comment #14)

I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case.

It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of DwmFlush), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.

Comment 16

[Robbie Khan]

(In reply to Yannis Juglaret [:yannis] from comment #15)

(In reply to Robbie Khan from comment #13)

Sure please see here:
https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link
(I don't see an option in the message box here to attach so Gdrive link instead)

Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian).

Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox triggers the DwmFlush at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz?

Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profiles you recorded, in the Privileged Content process's markers. The accessibility notifications appear there as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed?

(In reply to Robbie Khan from comment #14)

I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case.

It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of DwmFlush), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.

Hi,

To test, I set the refresh rate to 60Hz and ran the profiler:
https://share.firefox.dev/4f03Gvf

Note that I also heard the CPU fan ramp up as before, so whatever the actual numbers show (have not checked it directly myself), audibly I know that the same CPU impact is being observed at 60Hz else my CPU fan would not ramp up to the same levels again. This should not be a relevant issue though as no other browser seems to have this problem on a high refresh rate display in this same way and others have commented saying they see the same issue with FF too.

I do use Windows magnifier, I edit and pixel peep photos so need to use the magnifier often but I activate it as and when needed with WINKEY and +/-, all other times, inc when web browsing, magnifier is off (at default 100%) so not sure why Firefox thinks it is on. I also note that in about:config, 'layout.accessiblecaret.magnifier.enabled' is disabled (default).

Comment 17

[Yannis Juglaret [:yannis]]

(In reply to Robbie Khan from comment #16)

To test, I set the refresh rate to 60Hz and ran the profiler:
https://share.firefox.dev/4f03Gvf

Note that I also heard the CPU fan ramp up as before, so whatever the actual numbers show (have not checked it directly myself), audibly I know that the same CPU impact is being observed at 60Hz else my CPU fan would not ramp up to the same levels again. This should not be a relevant issue though as no other browser seems to have this problem on a high refresh rate display in this same way and others have commented saying they see the same issue with FF too.

We don't know (yet) what's common between your config and these other people's config that mine (for example) doesn't have, which is why I'm asking to test things that get your config as standard as possible. Thank you for your help with that!

I do use Windows magnifier, I edit and pixel peep photos so need to use the magnifier often but I activate it as and when needed with WINKEY and +/-, all other times, inc when web browsing, magnifier is off (at default 100%) so not sure why Firefox thinks it is on. I also note that in about:config, 'layout.accessiblecaret.magnifier.enabled' is disabled (default).

Could you set accessibility.force_disabled to 1 in about:config and restart Firefox -- and see if the issue still occurs? This should prevent the interference that using Magnifier (even intermittently and with another app) might have, as well as any other program using the accessibility API. Other than that, I think the next step will be to wait for :mstange's help here.

Comment 18

[Robbie Khan]

(In reply to Yannis Juglaret [:yannis] from comment #17)

(In reply to Robbie Khan from comment #16)

To test, I set the refresh rate to 60Hz and ran the profiler:
https://share.firefox.dev/4f03Gvf

Note that I also heard the CPU fan ramp up as before, so whatever the actual numbers show (have not checked it directly myself), audibly I know that the same CPU impact is being observed at 60Hz else my CPU fan would not ramp up to the same levels again. This should not be a relevant issue though as no other browser seems to have this problem on a high refresh rate display in this same way and others have commented saying they see the same issue with FF too.

We don't know (yet) what's common between your config and these other people's config that mine (for example) doesn't have, which is why I'm asking to test things that get your config as standard as possible. Thank you for your help with that!

I do use Windows magnifier, I edit and pixel peep photos so need to use the magnifier often but I activate it as and when needed with WINKEY and +/-, all other times, inc when web browsing, magnifier is off (at default 100%) so not sure why Firefox thinks it is on. I also note that in about:config, 'layout.accessiblecaret.magnifier.enabled' is disabled (default).

Could you set accessibility.force_disabled to 1 in about:config and restart Firefox -- and see if the issue still occurs? This should prevent the interference that using Magnifier (even intermittently and with another app) might have, as well as any other program using the accessibility API. Other than that, I think the next step will be to wait for :mstange's help here.

No problem!

Here is the profiling with that value set to 1, I can hear the CPU fan ramp up so doesn't appear to have made any difference:

https://share.firefox.dev/3Zneq0O

Comment 19

[gdansel]

I'll just chime in and say I'm experiencing the exact same issue, on Windows 11 24h2 with a 240hz display. If you want me to run WPF/ETW, let me know.

Comment 20

[Metaligh]

I couldn't figure out what was draining my laptop's battery for days, until I discovered that firefox and dwm.exe were loading the CPU at 40w idle. The laptop running on battery just dies. Windows 24H2. Right now I can't use firefox and it's very frustrating.

Comment 21

[Adrien Thébault]

Same issue here on Windows 11 24H2. At first I thought it was some kind of malware until I found the Reddit thread.

Here are my specs in case it helps :

• Windows 11 24H2 (Build 26100.2605)
• Firefox 133.0.3
• Ryzen 9 9950X (Impact : + ~12% utilization - roughly 4 threads at 100%, +20°C, +50W power consumption)
• GeForce RTX 3080
• While my main screen is a 144Hz, the one on which Firefox usually is, is a 60Hz.
• I also have a Logitech software running (Logitech GHub)

Comment 22

[Robbie Khan]

Still exists with the new version of Firefox this week.

Comment 23

[Green]

Got same problem on Windows 11 24H2 (Build 26100.2605), Core I9 13900KF, RTX 4090, Firefox 134.0
Feels like when FF stops getting signal from GPU it starts using CPU, tried to turn off gfx.webrender.fallback.software but it didnt help :(
Guess there is option to leave GPU always on, but dont wanna manually turn off monitors.
For temp fix made little script that kills firefox when computer is locked.

Comment 24

[Metaligh]

(In reply to Green from comment #23)

Got same problem on Windows 11 24H2 (Build 26100.2605), Core I9 13900KF, RTX 4090, Firefox 134.0
Feels like when FF stops getting signal from GPU it starts using CPU, tried to turn off gfx.webrender.fallback.software but it didnt help :(
Guess there is option to leave GPU always on, but dont wanna manually turn off monitors.
For temp fix made little script that kills firefox when computer is locked.

I think it's time for this script to be shared and installed with the application. Share pls the code. :-)

Comment 25

[Green]

(In reply to Metaligh from comment #24)

I think it's time for this script to be shared and installed with the application. Share pls the code. :-)

Nothing special just this line kills ff:
Get-Process -Name firefox -ErrorAction SilentlyContinue | Stop-Process -Force

Added it to Task Scheduler to trigger on event ID 4800 (The workstation was locked)

If not familiar with Task Scheduler u can run in powershell

while ($true) {
	$lockStatus = (Get-EventLog -LogName Security -Newest 5 | Where-Object {$_.EventID -eq 4800}).TimeGenerated
	if ($lockStatus) {
		Write-Host "lock time: $lockStatus"
		Get-Process -Name firefox -ErrorAction SilentlyContinue | Stop-Process -Force
	}
	Start-Sleep -Seconds 5
}

It does pretty much the same, but u need to run it manually.

Comment 26

[gdansel]

You don't actually need to kill the process or anything. You just need to minimize Firefox so there is no window being rendered.
Well, I suppose another fullscreen application on top might work too; if it truly is an interaction with DWM that is cauing the issue, if there is no window to draw nothing appears to go wrong.

Also, I havn't had any issues on 23H2, and given all the other DWM related issues 24H2 has I'm just gonna point some fingers in that direction.

Comment 27

[Robbie Khan]

(In reply to gdansel from comment #26)

You don't actually need to kill the process or anything. You just need to minimize Firefox so there is no window being rendered.
Well, I suppose another fullscreen application on top might work too; if it truly is an interaction with DWM that is cauing the issue, if there is no window to draw nothing appears to go wrong.

Also, I havn't had any issues on 23H2, and given all the other DWM related issues 24H2 has I'm just gonna point some fingers in that direction.

Minimising doesn't work either as noted in the comments earlier. As long as Firefox is open, the issue can be observed. If it is minimised, then the issue /sometimes/ is not observed, but most of the time it is. I have done back to back testing both ways and it exists under both conditions. Only killing Firefox before screen lock solves the issue, so I just right click FF and click end task from the taskbar for now before I lock my machine, then load FF back up after I log back in as it takes not even 1s to resume all tabs and windows.

Obviously this is a temp workaround, this issue should not exist in the first place.

Comment 28

[Adrien Thébault]

Can confirm that it happens when minimized too

Comment 29

[Yannis Juglaret [:yannis]]

After following some links I think I may have found how chromium deals with this issue. Unfortunately the bug discussion there is marked as private. My understanding is that if we want to implement the same workaround, then in our D3DVsyncSource::VBlankLoop we should ensure that we always have waited for at least X ms before we do our fallback call to DwmFlush (in chromium X=16.6, in JUCE X=1).

Edit: In fact in this case we might not even want to fallback: if this is a monitor-off situation, my understanding is that DwmFlush will consume CPU for no benefits; the CPU consumption could be due to the inability to delegate tasks to the GPU when the monitor is off.

Comment 30

[Yannis Juglaret [:yannis]]

:mstange tells me that you might be the proper person to work on this, :ahale?

Comment 31

[Metaligh]

Here is a temporary solution, The application deletes the process if firefox is running: https://github.com/metaligh/firefoxkiller/tree/main

Comment 32

[Bob Hood [:bhood]]

Glenn, tossing this your way for a look-see. Anything stand out to you?

Comment 33

[Glenn Watson [:gw]]

(In reply to Bob Hood [:bhood] from comment #32)

Glenn, tossing this your way for a look-see. Anything stand out to you?

I don't think WR itself is the right component for this.

It's not quite clear to me from a quick scan above if the power consumption is directly coming from the vblank thread, or from work that WR is doing as a result of the vblank thread spinning so quickly. Either way, WR will only ever do work in response to a request from Gecko, so I think the right fix will be in Gecko code, either not invoking WR as often in this scenario, or a higher level fix to reduce the power consumption of the vblank thread.

I suspect Markus on the performance team would be best placed to look at this, as he has the most knowledge of how the vblank syncing works (though I note the comment in #30 that you've already asked Markus about this?). It may be a case that we don't have a clear current owner / maintainer for how the vblank thread operates on Windows?

I've moved it to the Performance component for now, but we may need to discuss on matrix and find an appropriate owner for this to get it sorted.

Comment 34

[Markus Stange [:mstange]]

I agree that WR is the wrong place, but I would put the responsibility of the Windows vsync implementation into Graphics. I was hoping someone on the Graphics team could pick this up.

Comment 35

[Ashley Hale [:ahale]]

I've definitely noticed this exact bug before, where if displays go into power save, the vsync timer begins firing at like 1000hz with no justification which wastes a non-trivial amount of energy, this also happens during a video driver installer where the displays are all temporarily removed and vsync goes to 1000hz.

I think it makes sense for someone in gfx to own the RefreshDriver infrastructure, because it is intimately related to compositors on each OS (which of course is more of a widget concern, but that border is fuzzy).

This is one of the pieces of code that has a high bar to meet in terms of quality, as it must maintain the lowest possible latency on delivery of requestAnimationFrame events to script and rendering based on that (for an example see https://www.vsynctester.com/ and accompanying rant https://www.vsynctester.com/firefoxisbroken.html which is still true), otherwise we lose most of our available bandwidth for video playback as in https://bugzilla.mozilla.org/show_bug.cgi?id=1820370 which I've debugged at length with gpuview and Firefox Profiler so I've become somewhat familiar with its quirks from the outside.

I find this kind of timing engine fascinating and I've written them before, so I have a special interest in it.

Comment 36

[BugBot [:suhaib / :marco/ :calixte]]

This bug was moved into the Performance component.

:robbiekhan, could you make sure the following information is on this bug?

• ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 37

[Robbie Khan]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #36)

This bug was moved into the Performance component.

:robbiekhan, could you make sure the following information is on this bug?

• ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

I don;'t actually have any memory usage issues or concerns, is this information still needed? All necessary information and steps to replicate has already been posted in this bug thread with detailed information from others too otherwise.

Comment 38

[Metaligh]

Tor Browser 14.0.4 (based on Mozilla Firefox 128.6.0esr) does not cause these consequences. Maybe this will be useful.

Comment 39

[Metaligh]

134.0.1 - was problem solved? The processor is not overloaded after an update in this mode.

Comment 40

[Metaligh]

For a while it didn't load the processor, now it does again.

Comment 41

[Yannis Juglaret [:yannis]]

(In reply to Robbie Khan from comment #37)

I don;'t actually have any memory usage issues or concerns, is this information still needed? All necessary information and steps to replicate has already been posted in this bug thread with detailed information from others too otherwise.

This is an automatic message posted by BugBot as a consequence of marking this bug as Performance. Sorry for the disruption.

(In reply to Metaligh from comment #38)

Tor Browser 14.0.4 (based on Mozilla Firefox 128.6.0esr) does not cause these consequences. Maybe this will be useful.

If that is the case then running mozregression between versions 128 and 131 could help identify a specific change in Firefox that would have resulted in this issue. This will ask you to reproduce the issue in a few different Nightlies, so it would be best if you had a way to reproduce that doesn't involve waiting 1 min each time for the screen to turn off. For example, if the issue reproduces when you turn off the screen on your own, you will lose less time.

Comment 42

[Bob Hood [:bhood]]

I'm moving this back to Graphics since Ashley has expressed a comfort/knowledge level with it. However, we will anxiously await the result of the requested mozregression in comment #41 before scheduling any time for it.

Comment 43

[Yannis Juglaret [:yannis]]

Adding a needinfo for Metaligh accordingly. More generally, anybody who reproduces the issue is invited to try doing the mozregression.

Comment 44

[Adrien Thébault]

(In reply to Yannis Juglaret [:yannis] from comment #43)

Adding a needinfo for Metaligh accordingly. More generally, anybody who reproduces the issue is invited to try doing the mozregression.

Tried it and it gave me "Bug 1895868" after a lot of tests but I don't think that's it. Using mozregression I was able to reproduce the issue on 128 and even went back to 100 (more than 2 years ago) and still had it happen. I don't think I had it on Win11 23H2, it seems to be a weird interaction with a recent Win11 update more than a regression in Firefox itself.

Comment 45

[John teBokkel]

I have noticed that the issue is only in firefox and not in Libre Wolf (134.0.1-1). I have no idea how much code is shared between them.

I have also noticed a two other programs that can cause the dwm interaction. I need to close the following programs in order to not have CPU usage spikes when screens go to sleep.

1. firefox
2. alacritty (https://github.com/alacritty/alacritty/issues/8403)
3. LittleBigMouse (https://github.com/mgth/LittleBigMouse/issues/399)

Comment 46

[Metaligh]

(In reply to Yannis Juglaret [:yannis] from comment #43)

Adding a needinfo for Metaligh accordingly. More generally, anybody who reproduces the issue is invited to try doing the mozregression.

"Ok" - No problem.

The problem appears after the 114 release. But neither 112 nor 113 are downloaded by the program. Sometimes you ask for 125, 126 opens, you ask for 127, 127 opens. Some kind of random +1.

I couldn't choose 112 or 113 release, but it was so long ago that it can hardly help.
Strangely, TOR on Mozilla Firefox 128.6.0esr doesn't glitch.

101.0a1 (2022-04-18) (64-bit OK
102.0a1 (2022-05-02) (64-bit) OK
106.0a1 (2022-08-22) (64-bi OK
111.0a1 (2023-01-16) (64-bit) OK
112 - Unable to find build info for 2023-03-13
113 - It opens 114.
114.0a1 (2023-04-10) (64-bit) problem
115.0a1 (2023-05-08) (64-bit) problem
116.0a1 (2023-06-05) (64-bit) problem
117.0a1 (2023-07-04) (64-bit problem
118.0a1 (2023-07-31) (64-bit) problem
119.0a1 (2023-08-28) (64-bi problem
123.0a1 problem
124.0a1 (2024-02-02) (6 problem
125.0a1 (2024-02-19) (64-bit) problem
126.0a1 (2024-03-18) (64-bit problem
127.0a1 (2024-04-15) (64-bit) - problem
128.0a1 (2024-05-27) (64-bit) - problem
129.0a1 (2024-06-17) (64-bit - problem
130.0a1 (2024-07-08) (64-bit - problem1
131.0a1 (2024-08-05) (64-bit) - problem
...

Comment 47

[Metaligh]

Also it's useful to use command

NirCmd.exe monitor off
to chutdown monitor.
https://www.nirsoft.net/utils/nircmd.html

Comment 48

[Yannis Juglaret [:yannis]]

Thanks to both of you for going through the mozregression process. I think this clarifies that it isn't a recent regression in our code and that our best bet for the moment is the info from comment 29.

Comment 49

[Daniel Veditz [:dveditz]]

(In reply to Metaligh from comment #46

Strangely, TOR on Mozilla Firefox 128.6.0esr doesn't glitch.

The Tor Browser turns off a number of features in Firefox, either to reduce fingerprintability or to reduce attack surface in features they consider optional and not worth the risk (for example, I think hardware accelerated graphics might be one of them). If the bad interaction is in one of those features then this is not surprising at all.

Comment 50

[Chris Lord [:cwiiis]]

Is there any progress on this? It feels like a bug that causes large, unnecessary usage of power, with a potentially easy fix ought to be high priority enough to not linger for 4 months.

Comment 51

[Danial Horton]

from what i've heard, under 24h2 the desktop no longer uses a "swap chain" presentation model. Instead, Direct Display is now used and allows direct rendering of desktops with any framerate to the display devices.

Comment 52

[Ashley Hale [:ahale]]

I'm going to take a look at fixing this soon, or at least investigate the mechanism a bit more, I really appreciate all of the fact discovery that has happened so far :)

Aside from the key issue here of bad idling during sleep, one other observation of my own is that I've noticed jank in certain video games on Windows if I have several Firefox windows open that are hidden but not minimized, and a video playing in a visible Firefox window, if I minimize all windows (pressing Win+D) and then just bring up the ones I care about, the jank is mostly or completely eliminated, it's not clear to me if that is related, but I will include it in my range of repro attempts as I think broadly speaking we want to have optimal vsync behavior here in all scenarios, as introducing jank either in the browser or in other apps is extremely undesirable, as is poor handling of sleep.

Comment 53

[Robbie Khan]

Yeah I think collectively it's pretty clear where the issue lies (at least from a non developer perspective!) so hopefully this is finally fixed!

Comment 54

[Danial Horton]

This also replicates if you've switched windows user accounts, screen doesn't even need to go off, just login to the other account while firefox is open in the first and any firefox (and waterfox too) processes will have DWM chewing cpu cycles.

I'd never have thought to look before seeing this bug.

Comment 55

[Jean-Luc Deprez]

Hi. Thanks for documenting/reporting this. It would have taken me forever to find the relation between DWM and Firefox. But the "cook on screen-off" was already driving me mad.

Also ❤️ for many years of Firefox. I’m not about to let Win 11 24H2 block me off.

Given the situation as documented here, I conceived a blunt but effective workaround, to buy some time until a fix materializes.

It involves Sysinternals PsSuspend
https://learn.microsoft.com/en-us/sysinternals/downloads/pssuspend

I noticed that a single run doesn’t seem to get them all, but 3 iterations turned out to be effective. Therefore I use these powershell scripts.

firefox-pause.ps1

Set-Alias -Name "pssuspend" -Value "C:\<path to>\pssuspend64.exe"


for ($i = 0; $i -lt 3; $i++) {
    pssuspend firefox
}

firefox-resume.ps1

Set-Alias -Name "pssuspend" -Value "C:\<path to>\pssuspend64.exe"


for ($i = 0; $i -lt 3; $i++) {
    pssuspend -r firefox
}

With Windows task scheduler I simply create two tasks "for the current user to be run in session".

Don’t forget to turn off the condition “to only run on AC”.

Triggers: Lock -> pause, Unlock -> resume.

Action: start a program

Program: powershell.exe

Arguments: -WindowStyle Hidden -ExecutionPolicy Bypass -File <script>

Start in: <script folder>

The -WindowStyle Hidden is optional. If passed it hides the terminal window. I’ve put in for lock but not for unlock, to remind myself that the workaround is in place.

Comment 56

[Danial Horton]

I should note, the thing i last said about account switching manifests on 23h2, so its not just 24h2 that is seeing this, the trigger is just different on 23h2.

Comment 57

[Ashley Hale [:ahale]]

I've been reading all of the relevant code to make a decision on how I want to fix this, I want to make sure I understand whether there are reliable sources of display loss information here, because we already query for display information, if Windows considers the displays to be removed during this display power off state, then that would be a fantastic signal to do a power saving loop (e.g. we could sleep for as long as 50ms, because responding in 1/20th of a second to a display powering back on is likely adequate for comfortable user experience).

If we don't have a reliable source of information on the display status then the chromium approach is likely best, but I want to make sure it is both robust and does not impact framerates in normal operation (because now many monitors are 120hz or higher), so I need to test a bit.

Comment 58

[aafn]

Just to add my voice, I was going through the same investigation process because hearing my cpu fan going up as soon as the display is going into standby mode, and going quiet as soon as the display is on again.
A process monitor with 10s interval is showing me DWM.EXE as the culprit, but this is not happening when FF is not running as said above ..

Happy to see that I am not the only one, I was starting to get crazy with this ..

Windows 11 24H2
Display refresh rate = 74.97 Hz (so the problem is not only related to high refresh rates on displays ..)
Graphic card = NVidia 4070 Super, latest driver
FF 135.0.1

Comment 59

[Ashley Hale [:ahale]]

My understanding is that once the displays go to sleep, DWM starts spinning as fast as it can, whether that is 1000hz or higher I am not sure, but either way it's not something we want it to be doing, Firefox is just not doing the optimal thing to idle in this case currently.

Comment 60

[Ashley Hale [:ahale]]

Attachment: Bug 1924932 - add markers to WindowsVsyncThread for profiling r?#gfx-reviewers

Comment 61

[Ashley Hale [:ahale]]

I've found repro steps as follows:

• save the following text to a powershell script named something like turnoff-monitors.ps1:

(Add-Type '[DllImport("user32.dll")]
public static extern int PostMessage(int hWnd, int hMsg, int wParam, int lParam);' -Name User32 -Passthru)::PostMessage(-1,0x0112,0xF170,2)

• apply the patch in comment #60 to add profiler markers to describe what decisions VBlankLoop is making, build as normal (./mach build) and run the local build (./mach run).
• in the browser that opened go to profiler.firefox.com and click the Add Profiler button, change to Graphics mode, then click Edit Settings next to the dropdown, add ,WindowsVsyncThread to the custom threads list. (when conducting this test repeatedly without a ./mach clobber between, you may skip this step)
• open another tab in this window and go to a twitch.tv channel of your choice
• open another window and make it large enough to obscure the content area of the other window that has twitch playing
• turn on the profiler using the tool icon as normal
• run the powershell script described above, and wait at least a few seconds before moving the mouse to wake the displays back up
• turn off the profiler, and you should now have a profile of the issue
• when looking at the profile, make sure you turn on the WindowsVsyncThread channel under the main process if it is not automatically shown and take a look at the Marker Chart, if it shows DwmFlush running in a continuous loop - this is the issue.

Here is a profile I captured https://share.firefox.dev/3F3epsy

I'm looking at how to change this logic to resolve the issue.

Comment 62

[Ashley Hale [:ahale]]

Tested falling back to software vsync and that seems to be a good mitigation. Profile markers with that in place: https://share.firefox.dev/4irti6c

Comment 63

[Ashley Hale [:ahale]]

Attachment: Bug 1924932 - use software vsync when monitors are off r?#gfx-reviewers

Comment 64

[Sotaro Ikeda [:sotaro]]

Firefox on Windows has a capability to throttle window rendering based on window state that is managed by WinWindowOcclusionTracker. See Bug 1688997.

Window occlusion state is defined like

• https://searchfox.org/mozilla-central/source/widget/WindowOcclusionState.h#15

It throttles window rendering in the following situations

• Window is occluded by other window
• Window is minimized
• Window is not on the current virtual desktop
• Screen is locked
  • pref widget.windows.window_occlusion_tracking_session_lock.enabled

And optionally, when display is off. It is disabled by pref by default.

• pref widget.windows.window_occlusion_tracking_session_lock.enabled

By the way, window occlusion state could be shown in UI by pref gfx.webrender.debug.window-visibility = true.

I wonder if window occlusion throttling stopped to work correctly at some point. It might be around WinWindowOcclusionTracker or AppWindow::OcclusionStateChanged() does not work as expected.

Comment 65

[Sotaro Ikeda [:sotaro]]

Sorry for comment 64, I did not looked into comments in this bug. The problem seems to exists around vsync handling. And window occlusion seems to works as expected.

Comment 66

[Sotaro Ikeda [:sotaro]]

Attachment: diagram around Vsync handling in gecko

This diagram shows how vsync is handled in gecko.

Comment 67

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #64)

I wonder if window occlusion throttling stopped to work correctly at some point. It might be around WinWindowOcclusionTracker or AppWindow::OcclusionStateChanged() does not work as expected.

I looked into if AppWindow::OcclusionStateChanged() is handled as expected in gecko.

With the following STR, there were cases that nsRefreshDriver continued to tick with VsyncRefreshDriverTimer and Vsync keeps running. It seemed like a problem.

• [1] Start Firefox
• [2] Move to https://www.youtube.com/watch?v=LXb3EKWsInQ
• [3] Start video playback
• [4] Move the Firefox window to be occluded by other app window

Comment 68

[Sotaro Ikeda [:sotaro]]

Created Bug 1952787 for comment 67.

Comment 69

[Sotaro Ikeda [:sotaro]]

deleted

Comment 70

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8f788f19517b
use software vsync when monitors are off r=gfx-reviewers,aosmond

Comment 71

[Ashley Hale [:ahale]]

Comment on attachment 9469887 [details]
Bug 1924932 - use software vsync when monitors are off r?#gfx-reviewers

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: High CPU usage on Windows specifically when laptop lid is closed or screen is locked, where constantly calling DwmFlush causes the dwm.exe (Desktop Compositor) to reach 100% CPU, causing battery drain and fan noise on laptops, I believe this occurs only when a video is playing in the active tab of a window that is not minimized, and other windows cover up the video - this happens most for people with a lot of open windows. This patch only reduces the CPU usage - the video should not even be playing in this case, but that will be addressed by https://bugzilla.mozilla.org/show_bug.cgi?id=1952787 in future.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: Repro instructions are in https://bugzilla.mozilla.org/show_bug.cgi?id=1924932#c61
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch changes the logic to match chromium, which has been using this approach for years now.
• String changes made/needed:
• Is Android affected?: No

Comment 72

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/8f788f19517b

Comment 73

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/80a947164682

Comment 74

[Donal Meehan [:dmeehan]]

Comment on attachment 9469887 [details]
Bug 1924932 - use software vsync when monitors are off r?#gfx-reviewers

Approved for 136.0.2

Comment 75

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/6efb242185fd

Comment 76

[Phabricator Automation]

Comment on attachment 9469647 [details]
Bug 1924932 - add markers to WindowsVsyncThread for profiling r?#gfx-reviewers

Revision D240288 was moved to bug 1959878. Setting attachment 9469647 [details] to obsolete.