Closed Bug 1738926 Opened 4 years ago Closed 4 years ago

Playing video in full screen causes excess WindowServer CPU usage

Categories

(Core :: Audio/Video: Playback, defect, P1)

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 94
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
98 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox93 --- unaffected
firefox94 + wontfix
firefox95 + wontfix
firefox96 + disabled
firefox97 + disabled
firefox98 --- fixed

People

(Reporter: martin.racak, Assigned: bradwerth)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: power, regression)

Attachments

(5 files, 2 obsolete files)

Sample of WindowServer - low CPU.txt
538.21 KB, text/plain
Details
Sample of WindowServer - high CPU.txt
442.20 KB, text/plain
Details
Screenshot 2021-11-09 at 21.28.01.png
3.45 MB, image/png
Details
Bug 1738926 Part 1: Check if sublayers need to be rebuilt.
48 bytes, text/x-phabricator-request
Details | Review
Bug 1738926 Part 2: Stop enqueueing video when the layer gets overwhelmed.
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I'm on a MacBook Pro (13-inch, 2020) with macOS Monterey 12.0.1. Happens also in Troubleshoot Mode. I can reproduce by following these steps:

  1. Start Firefox by clicking on the desktop icon
  2. Open https://www.youtube.com/watch?v=aqz-KE-bpKQ in a new tab
  3. Play the video in full screen
  4. Open Activity Monitor
  5. WindowServer shows up to 200% CPU usage
  6. Close tab with the video
  7. WindowServer stays at around 100% CPU

Actual results:

Video played normally, but fan quickly started spinning a lot. WindowsServer was using high percentage of CPU.

Expected results:

No excess CPU usage.

Wasn't able to reproduce in Nightly.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Actually I'm able to reproduce also in Nightly. It happens only when video plays in low quality and in full screen, e.g. 480p. At 1440p60 I see normal WindowServer CPU usage. Also it drops to normal levels after I close the tab, but only after around 45 seconds.

Is this a regression, or has it always been this way for you? If it's a regression, could you use https://mozilla.github.io/mozregression/ to pin down where it began?

Flags: needinfo?(martin.racak)

Could you get a sample of the WindowServer process using Activity Monitor? Or actually two, one in the low quality (high CPU) case and one in the high quality (low CPU) case.

(In reply to Jon Bauman [:jbauman:] from comment #4)

Is this a regression, or has it always been this way for you? If it's a regression, could you use https://mozilla.github.io/mozregression/ to pin down where it began?

I was able to pin it down to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c9a191f99fa323e42bc664320d160b4ff4f3f4f1&tochange=af7e7b1d891ee07ec15c3702cbce8f509679b82a

Flags: needinfo?(martin.racak)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Regressed by: 1731815
Has Regression Range: --- → yes

(In reply to Markus Stange [:mstange] from comment #5)

Could you get a sample of the WindowServer process using Activity Monitor? Or actually two, one in the low quality (high CPU) case and one in the high quality (low CPU) case.

Attached the samples.

Thanks!

The big difference I see is in the com.apple.skylight.stats dispatch queue. The "high CPU" sample is spending all of its time in __WSDataTimelinePushWindowStateForCurrentTime_block_invoke.

I've filed FB9736101 about this. Martin, it would be helpful if you filed a feedback report with Apple about this as well, so that the tool can collect information about your machine.

Maybe we can find out how to avoid hitting this expensive path, with some debugging...

Sure, I could try. But I don't know how does one do that or which tool you have in mind. Could you point me to some relevant docs?

Oh yes, sorry, instructions are here: https://developer.apple.com/bug-reporting/

Thanks. I have the Feedback Assistant app open, but I'm not sure which problem area should I pick. Just 3rd Party Apps? Or some SDK? And write down basically the same repro steps we have here? I wanted to check your report for inspiration, but I wasn't able to find a way to read it anywhere.

I filed mine under AVFoundation but I wasn't sure about the right component either - there doesn't seem to be one for the window server. Maybe file yours under "Graphics" or under "System Slow / Unresponsive". And yes, the basic steps to reproduce (with affected Firefox versions) should be enough.

OK, submitted FB9736269. Chose "Graphics" as the problem area.

I watched more YouTube videos and it also happens at 1440p, for example https://www.youtube.com/watch?v=LcI6F_GPwfE It uses the same codec (VP9) as the one where it didn't happen. One obvious difference is FPS - 60 good, 30 bad.

Severity: -- → S3
Priority: -- → P3

Changing the priority to p1 as the bug is tracked by a release manager for the current release.
See What Do You Triage for more information

Priority: P3 → P1

I'm unable to replicate this with either video, at any resolution on my MacBook Pro running Monterey. Are you by chance using an external monitor?

Flags: needinfo?(martin.racak)

No, just the built-in. Hmm, trying to think of things that could be relevant:

  • Scaled resolution – 1280 x 800
  • True Tone on
  • Night Shift on
  • Dynamic desktop (lol)

Switching them off/to default didn't help. This is my Graphics/Displays section from system report:

Intel Iris Plus Graphics:

  Chipset Model:	Intel Iris Plus Graphics
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1536 MB
  Vendor:	Intel
  Device ID:	0x8a53
  Revision ID:	0x0007
  Metal Family:	Supported, Metal GPUFamily macOS 2
  Displays:
Colour LCD:
  Display Type:	Built-In Retina LCD
  Resolution:	2560x1600 Retina
  Framebuffer Depth:	30-Bit Colour (ARGB2101010)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Automatically Adjust Brightness:	Yes
  Connection Type:	Internal

Checked about:support after I hit the issue just now and found this:

Failure Log
(#0) 	CP+[GFX1-]: Managed to allocate after flush.
(#1) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#2) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#3) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#4) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#5) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#6) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#7) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)
(#8) Error	Failed to allocate a surface due to invalid size (CDT) Size(0,0)

I didn't realize failure logs could be there before. Is there any other info that would help? Is it possible to generate more logs?

Flags: needinfo?(martin.racak)

Thank you for the info on your graphics setup. Mine is similar, but I have Intel UHD Graphics 630. I still can't replicate by changing my resolution and settings to match yours. I'll keep trying things.

Is anyone looking into this?

Flags: needinfo?(jmuizelaar)

(In reply to Marco Castelluccio [:marco] from comment #22)

Is anyone looking into this?

I am, but until I can reproduce, I've been hesitant to assign myself to the bug. And I can't reproduce. Given that it doesn't occur for the reporter in Nightly, this might have been fixed by recent work that didn't get uplifted.

Martin, are you willing to run the mozregression tool to help us understand what's going on here? You'd be using the --find-fix option with a date range from October 20th to today.

Flags: needinfo?(jmuizelaar) → needinfo?(martin.racak)

As I said in comment 3 I was able to reproduce it also in Nightly. Just checked again with the latest Nightly and it is still the case. Maybe you missed this before and didn't try to set the quality manually when trying to reproduce? On top of that in comment 17 I found out that the difference seems to be in FPS, not resolution, but not sure.

So to recap: Playing https://www.youtube.com/watch?v=aqz-KE-bpKQ in full screen in 480p (which should be 30 FPS or maybe less?) causes WindowServer to go up to 200% CPU. With 720p60 (which should be 60FPS) it stays at around 30%.

Flags: needinfo?(martin.racak)

(In reply to Martin Račák from comment #24)

As I said in comment 3 I was able to reproduce it also in Nightly. Just checked again with the latest Nightly and it is still the case. Maybe you missed this before and didn't try to set the quality manually when trying to reproduce? On top of that in comment 17 I found out that the difference seems to be in FPS, not resolution, but not sure.

You're right; I'm sorry I missed that. In my attempts to reproduce, I am setting the quality level to 420p and I'm getting WindowServer usages in the 50% range. I'll see if I can do something to artificially limit the FPS and see if it triggers the high usage. I suspect the sub-30 FPS is an effect, not a cause, but I'll investigate.

Assignee: nobody → bwerth

Though I still can't reproduce, here's a theory of what's happening: in low-FPS conditions, perhaps the WindowServer is not able to maintain the detached mode, and so it cycles in and out of the detached mode rapidly (with every frame?). I'll build a patch that abandons our attempt to enter detached mode if the frame rate is below some threshold, and we'll see if that solves Martin's reproduction case.

Martin, are you able to reproduce the problem on sites other than YouTube?

Flags: needinfo?(martin.racak)

Yes, on Twitch it's bad at 480p and lower and good at 720p60 and above. Very similar on Vimeo, but their player seems to respect chosen video quality less and maybe uses higher quality when there is bandwidth or it's just bugged. But when it plays in low quality it definitely also goes up to 200% CPU.

Flags: needinfo?(martin.racak)

Martin, can you try downloading Quartz Debug? You can get it from here: https://developer.apple.com/download/all/?q=quartz%20debug or more conveniently here: https://github.com/jrmuizel/quartz-debug/files/7507362/Quartz.Debug.app.zip

When you run it, there's a "Show Detached Regions" menu entry under the "Tools" menu. Enable it. It should tint everything red. However, when full screen video is using detached mode the tint will go away. Can you try running the 480 and the 720 in Firefox that the red tint goes away. Can you also check if you see the red tint go away in Chrome and Safari on Twitch and Vimeo? Do you also see high cpu usage in the WindowServer when running the lower quality videos in Chrome or Safari?

Flags: needinfo?(martin.racak)

Tested only YouTube so far, because it seems that either the tool isn't working or the video is never using detached mode (yes, it was full screen).

Video: https://youtu.be/aqz-KE-bpKQ

Browser Quality Red tint
Nightly 480p yes
Nightly 720p60 yes
Chrome 480p yes
Chrome 720p60 yes
Safari 480p yes
Safari 720p60 yes

Neither Chrome nor Safari cause high CPU usage and Safari seems to be the most efficient in that regard, but that is just me looking at Activity Monitor. CPU usage in Firefox was also OK before the change I identified as regression in comment 6.

Flags: needinfo?(martin.racak)

Is the QuartzDebug overlay window visible? In that case, could you try again with it closed? Detached mode is only hit if no other windows, or really nothing other than the video and a black background, are visible. On some machines it looks like the mouse cursor has to be invisible too.

Yes, this is how my screen looks when it is playing (the tint was there, but isn't captured on the screenshot). Funnily enough, some important process must have crashed shortly after I took the screenshot in Nightly because I got logged off and after logging in all my processes restarted.

I now realized that was a bit ambiguous. So to be clear: no other windows or cursor was visible, just the video.

That video has an annotation so you won't hit detached mode unless annotations are turned off. Can you try turning the annotation off and seeing if that lets you get detached mode and if it makes a difference for cpu usage?

Flags: needinfo?(martin.racak)

Martin, my theory in comment 26 is much less likely if you are not hitting detached mode. And since most of the recent code changes to video on macOS are related to that detached mode, it's hard to guess what might be going on here. In case this is unrelated to detached mode, would you please run a mozregression on your machine to find which bit of code started triggering this problem for you?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #34)

That video has an annotation so you won't hit detached mode unless annotations are turned off. Can you try turning the annotation off and seeing if that lets you get detached mode and if it makes a difference for cpu usage?

Finally some progress! When I turn the annotations off the red tint stays, but WindowServer CPU oscillates at around 30%.

(In reply to Brad Werth [:bradwerth] from comment #35)

In case this is unrelated to detached mode, would you please run a mozregression on your machine to find which bit of code started triggering this problem for you?

I already ran mozregression in comment 6. I don't think it makes sense to run it again, does it?

Flags: needinfo?(martin.racak)

Edit: this comment is wrong

Very interesting. All prerequisites for detachment are met, but you don't get detachment. Hypothesis: Maybe the WindowServer attempts to detach, fails, and then reports the error somewhere, and the error reporting is what's causing the CPU usage.

Oh, sorry, I got it backwards. 30% is the low value, 200% is the high value. So that means if we're actually isolating successfully, CPU usage is low, but we're still not detached for some reason.

Sorry, it's getting late here, I didn't check carefully enough with annotations off. Now I repeated the experiment from before with annotations turned off in each browser.

Video: https://youtu.be/aqz-KE-bpKQ

Browser Quality Detached mode
Nightly 480p no
Nightly 720p60 yes
Chrome 480p no
Chrome 720p60 no
Safari 480p yes
Safari 720p60 yes

(In reply to Markus Stange [:mstange] from comment #38)

Oh, sorry, I got it backwards. 30% is the low value, 200% is the high value. So that means if we're actually isolating successfully, CPU usage is low, but we're still not detached for some reason.

Yup, that sounds plausible.

This prevents detached mode if a less-than-20fps frame has been hit in the
last 5 seconds.

Brad are you planning a fix in 96 that could be uplifted to beta or should we mark 95 as wontfix at this point of the release cycle?

Flags: needinfo?(bwerth)
See Also: → 1740360
Attachment #9250092 - Attachment is obsolete: true

This fixes a correctness issue. Since NativeLayerCA Representations can
generate new CALayers under certain conditions, the NativeLayerRootCA must
check to see if a rebuild is necessary when committing.

This change makes the decision of whether or not to specialize the video layer
(to choose a AVSampleBufferDisplayLayer over a CALayer) dependent upon
whether or not the video layer is currently isolated. This means that the
NativeLayerCA may generate new CALayers at times when it hasn't been given a
new surface to display. To compensate for this, the current surface is now
captured and reused.

Depends on D131307

Martin, I'd like to see if the proposed patch solves the problem for you. Would you please download and try out this build and report how it behaves with your testcases?

Flags: needinfo?(martin.racak)

At 480p with annotations on, WindowServer CPU oscillates around 22% (was up to 200% before), so that case seems to be fixed! With annotations off it still won't enter detached mode and WindowServer stays at around 30% (like before), maybe because it keeps trying to enter detached mode and fails?

Unfortunately at 780p60 there seems to be a regression. With annotations off and after playing in detached mode for some time WindowServer CPU sometimes goes up to 200%, but I'm not able to reproduce it reliably. With annotations on (no detached mode) it stays around 35% and Firefox NighltyCP RDD Process oscillates 30% – 70%, which I haven't seen in other cases (or before, I think).

Overall when looking at Activity Monitor different processes now seem to behave less deterministically with regard to their CPU usage, but that is just my impression.

Flags: needinfo?(martin.racak)

(In reply to Martin Račák from comment #46)

At 480p with annotations on, WindowServer CPU oscillates around 22% (was up to 200% before), so that case seems to be fixed! With annotations off it still won't enter detached mode and WindowServer stays at around 30% (like before), maybe because it keeps trying to enter detached mode and fails?

With annotations on, it will never even try to enter detached mode, so any improvements there we should consider as fixes. Annotations off, we could be trying to reach detached mode, but we don't know what the WindowServer is doing. If the Quartz Debug tool "Show Detached Regions" feature turns off the red tint then we are in detached mode and we have to assume that is reliable reporting.

So if some cases you are still getting high CPU, we need to know if they are occurring during:

  1. Steady red tint: we're attempting to reach detached mode but the WindowServer is rejecting it.
  2. Absent the red tint: we've reached detached mode but the WindowServer is doing something that exercises the CPU.
  3. Toggling between the red tint and normal: we are entering and leaving the detached mode, which might mean we are regenerating layers unnecessarily.

Unfortunately at 780p60 there seems to be a regression. With annotations off and after playing in detached mode for some time WindowServer CPU sometimes goes up to 200%, but I'm not able to reproduce it reliably. With annotations on (no detached mode) it stays around 35% and Firefox NighltyCP RDD Process oscillates 30% – 70%, which I haven't seen in other cases (or before, I think).

This sounds like case 2. Can you try to replicate this (with the patched build) and note if the detached mode toggles off (no red tint) when the CPU is high?

Sorry to put you through all this testing, but we're still trying to find hardware that replicates the issue you're seeing. In the meantime, this patch seems like it is an improvement so I'll start the review process.

(In reply to Brad Werth [:bradwerth] from comment #47)

Annotations off, we could be trying to reach detached mode, but we don't know what the WindowServer is doing. If the Quartz Debug tool "Show Detached Regions" feature turns off the red tint then we are in detached mode and we have to assume that is reliable reporting.

Just to avoid potential confusion here – when I say it does or doesn't enter detached mode it's a result of my tests with the Quartz Debug tool, I'm not merely guessing.

This sounds like case 2. Can you try to replicate this (with the patched build) and note if the detached mode toggles off (no red tint) when the CPU is high?

I tried a few combinations of things and wasn't able to reproduce the state I randomly hit before where WindowServer CPU stayed near 200% when playing 720p60 with annotations off. However, what seems to replicate is when I open the video, turn annotations off and start playing at 480p (which doesn't enter detached mode). Then while it's playing I change the quality to 720p60 and it quickly enters detached mode. I let it play for a few seconds and then check the Activity Monitor. WindowServer quickly shoots up to 200% CPU and then somewhat slower comes down to about 35% again, where it seems to stay.

(In reply to Martin Račák from comment #48)

(In reply to Brad Werth [:bradwerth] from comment #47)

Annotations off, we could be trying to reach detached mode, but we don't know what the WindowServer is doing. If the Quartz Debug tool "Show Detached Regions" feature turns off the red tint then we are in detached mode and we have to assume that is reliable reporting.

Just to avoid potential confusion here – when I say it does or doesn't enter detached mode it's a result of my tests with the Quartz Debug tool, I'm not merely guessing.

Yes, I'm sorry, I chose my words poorly here. I mean reliable reporting by the WindowServer that it is actually in detached mode and not merely attempting to reach it and doing extra work in the background that might push the CPU.

Seems like the proposed patch is an improvement, possibly even a fix. We'll continue with the review process and I'll try to get it landed.

Flags: needinfo?(bwerth)

I'm going to land D131307 separately and leave this bug open while we work through the more complicated changes.

Keywords: leave-open
Pushed by bwerth@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e45b20ce3924 Part 1: Check if sublayers need to be rebuilt. r=mstange

Just wanted to mention that I'm also having this issue on Chrome. It will happen reliably if I watch Twitch in full screen for a few minutes. I also noticed there's a bug report for video.js here: https://github.com/videojs/video.js/issues/7520

Also the video on Twitch I'm watching is 864p60 (I noticed discussion up above about it perhaps only occurring sub 720p)

Martin, new build to try, that uses a different approach to hopefully solve the problem. Would you please try this build with your problematic cases?

Flags: needinfo?(martin.racak)

Unfortunately, it does not solve it. At 480p, with annotations both on and off, WindowServer CPU goes up to 200%.

Flags: needinfo?(martin.racak)

Just wanted to throw my hat into the ring as well and say that I've also been experiencing this issue. Running a YouTube video (https://www.youtube.com/watch?v=iPzPZTmUt1E) at 720p and going fullscreen for several seconds pushes the WindowServer process up to and slightly above 100%. I've noticed that in the newest release, it eventually resets whereas before I had to reboot my computer or kill the process in Activity Monitor to reset it.

Firefox version: Firefox 94.0.2 (64-bit)
Model Name: MacBook Pro
Model Identifier: MacBookPro18,3
Chip: Apple M1 Pro
Total Number of Cores: 8 (6 performance and 2 efficiency)
Memory: 16 GB
System Firmware Version: 7429.41.5
OS Loader Version: 7429.41.5

(In reply to jbwzrd213 from comment #57)

Just wanted to throw my hat into the ring as well and say that I've also been experiencing this issue. Running a YouTube video (https://www.youtube.com/watch?v=iPzPZTmUt1E) at 720p and going fullscreen for several seconds pushes the WindowServer process up to and slightly above 100%. I've noticed that in the newest release, it eventually resets whereas before I had to reboot my computer or kill the process in Activity Monitor to reset it.

Firefox version: Firefox 94.0.2 (64-bit)
Model Name: MacBook Pro
Model Identifier: MacBookPro18,3
Chip: Apple M1 Pro
Total Number of Cores: 8 (6 performance and 2 efficiency)
Memory: 16 GB
System Firmware Version: 7429.41.5
OS Loader Version: 7429.41.5

Also wanted to add that the Twitch player causes the bug as well. Unlike with YouTube, WindowServer doesn't seem to be going away on its own when caused by Twitch.

(In reply to Pascal Chevrel:pascalc from comment #41)

Brad are you planning a fix in 96 that could be uplifted to beta or should we mark 95 as wontfix at this point of the release cycle?

We are not on track to have a fix for 95. I hope to have a solution in time for uplift to 96, but we're not there yet.

It's starting to look like this is a bug with certain video players going fullscreen. I'm noticing the same WindowServer service around 100% after using the PlayStation Remote Play app in fullscreen for a few minutes.

I also hit this on an M1 Pro machine on both 94.0.2 and Nightly 11-26.

However, the build in comment #55 seems to be working much better.

(Note though that this is an Intel-only build.)

I can confirm that the nightly build from #55 also seems to correct the issue on an intel based apple air.
While FF 94 trigger the problem constatntly whithin just a few minutes, the nightly build (FF96.0a1 21.nov) is behaving stable on the same set of full screen videos.

With build from #55 on a M1 Max with the video from #39 at 720p60 I see the following behaviour:

  • With browser in window mode, windowserver stays at around 30% CPU.
  • With browser in Fullscreen mode, or video in fullscreen mode, windowserver stays over 100% CPU, but reverts back to 30% CPU if reverted in window mode or closed.

To reiterate, the video causes windowserver to consume much larger CPU resources even if the video itself is not in fullscreen mode, but the browser is.

With Firefox 95.0b12 I have the same beaviour, except that the windowserver stays at 100% CPU even after the browser or video are not fullscreen anymore or even after Firefox is closed.

I think there is also a memory leak involved: when I found about the issue I had windowserver stuck at 100% CPU and consuming about 45GB of memory. Not sure how long it was stuck in that state though.

Interesting. With build from #55 on a 16" M1 Pro, OS 12.0.1, only built-in display, with the video from #39 at 720p60 I see the following behaviour:

  • With browser in window mode and video playing, windowserver stays at around 22% CPU.
  • With video playing in fullscreen mode, windowserver stays at around 15% CPU.
  • With no video playing and only Firefox open, windowserver stays at about 3% CPU.

With both 94.0.2 and Nightly 11-26, I see windowserver at 100%, and it remains there even after quitting Firefox; a restart is required.

Note of course that other onscreen activity will also increase WindowServer usage. Christian, how are you logging the CPU usage in fullscreen mode? I used top -n4 > top.txt.

(In reply to Alexander from comment #64)

Note of course that other onscreen activity will also increase WindowServer usage. Christian, how are you logging the CPU usage in fullscreen mode? I used top -n4 > top.txt.

I used a second display, but after your comment I quickly tested with only the built-in display and redirecting the output of top in background.

While the video was playing I had similar results as my original test: low CPU use in browser windowed mode, high CPU use in browser fullscreen mode. Without video activity, windowserver idles at under 3% CPU.

Differently from my original test, this time, I got windowserver stuck at 100% for many minutes after the test, which didn't happen with the nightly build last time I tested. I don't understand the reason for this difference. Windowserver did eventually revert to normal though.

Nightly now contains the changes that were tested in the build in comment #55. That landed in Bug 1741982.

(In reply to Brad Werth [:bradwerth] from comment #66)

Nightly now contains the changes that were tested in the build in comment #55. That landed in Bug 1741982.

I tested with latest nightly (Build ID 20211129094259) and I still have issues as described in #63. Not sure how I can help with further testing.

That’s weird, it says that changeset landed in Nightly 11-25, but I had issues with Nightly 11-26. I’ll test the latest nightly again, but are you sure there were no other changes in that build?

(In reply to Alexander from comment #68)

That’s weird, it says that changeset landed in Nightly 11-25, but I had issues with Nightly 11-26. I’ll test the latest nightly again, but are you sure there were no other changes in that build?

I'm not sure that the changes from Bug 1741982 solve this bug. I hope they will have a positive effect at least, and maybe narrow the cases where this bug occurs. I don't think any other video layer code landed around the same time.

Did some more tests and apparently on my end the screen refresh rate plays a role. I have the ProMotion option per default which seems to cause the high CPU issues when in Fullscreen, but when I set 60Hz instead the issue disappears. Did only some quick tests though.

Furthermore, in the last Nightly there is some issue with the video scaling when switching to Fullscreen. After switching to Fullscreen the video seems to be wrongly zoomed in. This issue is not present in the build from #55.

I made screenshots of the issue here: https://imgur.com/a/eMpO522

(In reply to Christian from comment #70)

Furthermore, in the last Nightly there is some issue with the video scaling when switching to Fullscreen. After switching to Fullscreen the video seems to be wrongly zoomed in. This issue is not present in the build from #55.

I made screenshots of the issue here: https://imgur.com/a/eMpO522

I have opened Bug 1743474 on this issue.

I have a MacBook Pro 13-inch, 2018, with the following graphics card:

Intel Iris Plus Graphics 655:

  Chipset Model: Intel Iris Plus Graphics 655
  Type: GPU
  Bus: Built-In
  VRAM (Dynamic, Max): 1536 MB
  Vendor: Intel
  Device ID: 0x3ea5
  Revision ID: 0x0001
  Metal Family: Supported, Metal GPUFamily macOS 2
  Displays:
    Colour LCD:
      Display Type: Built-In Retina LCD
      Resolution: 2560x1600 Retina
      Framebuffer Depth: 24-Bit Colour (ARGB8888)
      Main Display: Yes
      Mirror: Off
      Online: Yes
      Automatically Adjust Brightness: Yes
      Connection Type: Internal

I ran the tests and couldn't see any surprising increase in CPU usage:

Windowed 1080p60: avg. 18% CPU (User)
Full-screen 1080p60: avg. 20% CPU (User)

Windowed 480p: avg. 10% CPU (User)
Full-screen 480p: avg. 11% CPU (User)

System usage in all cases: ~5%

I'm still seeing this issue in firefox nightly

i installed a clean install about 10 minutes before this post

i installed ublock origin

i logged into youtube and clicked on a 10 minute video

3-4 minutes into the video CPU usage spiked past 100% and stayed there.

Even after closing the video and waiting several minutes I still have north of 100% CPU usage on windowserver

The only workarounds I know about are forcequitting windowserver (forces you to log back in) or a hard reset.

This bug makes firefox unusable for me because if ever watch a video I need to regularly reboot my computer like it's the 90s again.

I did notice some improvement where after closing a video in nightly, after roughly 5-10 minutes CPU usage for windowserver goes back down to normal levels. On the regular builds it would never go back down unless I used one of the workarounds I mentioned.

Screenshots of system usage: https://imgur.com/a/xWtHqjn

Intel Iris Plus Graphics:

  Chipset Model:	Intel Iris Plus Graphics
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1536 MB
  Vendor:	Intel
  Device ID:	0x8a53
  Revision ID:	0x0007
  Metal Family:	Supported, Metal GPUFamily macOS 2
  Displays:
Color LCD:
  Display Type:	Built-In Retina LCD
  Resolution:	2560 x 1600 Retina
  Framebuffer Depth:	30-Bit Color (ARGB2101010)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Automatically Adjust Brightness:	Yes
  Connection Type:	Internal

I can confirm this bug on my MacBook Air (Retina, 13-inch, 2020, Intel, Monterey 12.0.1) on Firefox 94.0.2 and Chrome 96.0.4664.55. And I think this is an OS bug. For Chrome the problem is solved by disabling hardware acceleration

same problem on Macbook Air 13-inch, 2020 Intel Monterey 12.0.1 and Firefox 94.0.2

The Problem appeared with Monterey.

I can confirm that disabling hardware acceleration solved this completely for me.

Hope this helps other people in this thread.

I'm assuming that once the root cause is fixed we could turn hardware acceleration back on for better (?) overall performance.

On 16" M1 2021, ProMotion with or without acceleration still shows the issue. With the display set to 60Hz the issue disappears, with or without acceleration enabled.

(In reply to Hayk Saakian from comment #76)

I can confirm that disabling hardware acceleration solved this completely for me.

Hope this helps other people in this thread.

I'm assuming that once the root cause is fixed we could turn hardware acceleration back on for better (?) overall performance.

can't confirm that deactivating fixes the issue.

(In reply to dseinwill from comment #75)

same problem on Macbook Air 13-inch, 2020 Intel Monterey 12.0.1 and Firefox 94.0.2

The Problem appeared with Monterey.

the problem also happens with chrome 96.0.4664.55

On a 2020 Intel Mac Monterey 12.0.1 with Firefox 94.0.2, turning off hardware acceleration does not fix the problem.

Disabling ProMotion solves this issue for me (macbook pro 14" 2021, macos 12.0.1, Firefox 94.0.2). When playing a fullscreen youtube video WindowServer stays below 30% CPU.

I ran into the same problem with high CPU usage when playing videos. For me it started with the update (or shortly after) to Monterey about four weeks ago. To find the origin of the problem, macOS or Firefox, I have installed Catalina on an external drive where the current version of Firefox works perfectly fine (same settings). As of now, I have copied files and programs that I often use to the external drive, waiting for a fix on either macOS or Firefox, wherever the bug might be. Maybe that work around helps others.

I am using an i5 MacBook Air 2020

This issue appears to be corrected in Firefox 95. Example: https://www.youtube.com/watch?v=ab7NyKw0VYQ
2020 Macbook Air, Monterey 12.0.1

2020 Macbook Air and Monterey 12.0.1 - the problem still exists with firefox 95

Same here, problem still exists in 95...

But as I mentioned before, Firefox works perfectly fine on Catalina.

whatever safari is doing different - the problem only appears with firefox and chrome.

Beats me. The same two videos that caused this problem with Firefox 94 this morning do not cause it with Firefox 95. Nothing else changed. (FWIW release notes say it's fixed in 95.)

I think I found a much more acceptable work around than the one in comment #82. Instead of installing an old macOS, simply install the ESR version of Firefox. That seems to fix it for me. Hope that works for everyone.

Disabling ProMotion solves this issue for me (macbook pro 14" 2021, macos 12.0.1, Firefox 94.0.2). When playing a fullscreen youtube video WindowServer stays below 30% CPU.

Can confirm on M1 Max 16". Disabling promotion fixed high WindowServer CPU usage during playback and the lingering 100% CPU usage even after Firefox 95 is closed on MacOS 12.0.1.

(In reply to nate from comment #89)

Disabling ProMotion solves this issue for me (macbook pro 14" 2021, macos 12.0.1, Firefox 94.0.2). When playing a fullscreen youtube video WindowServer stays below 30% CPU.

Can confirm on M1 Max 16". Disabling promotion fixed high WindowServer CPU usage during playback and the lingering 100% CPU usage even after Firefox 95 is closed on MacOS 12.0.1.

Thanks for providing your findings for this issue. Our current hypothesis is that high refresh displays are causing this problem for us, and when we exhibit this issue, Chrome is also exhibiting the issue. Would you please re-enable ProMotion and check if the problem also happens for you in Chrome?

Not fixed with Monterey 12.1 unfortunately. Was hoping they'd sort it out.

Attachment #9251045 - Attachment is obsolete: true

It would /appear/ that this has been fixed in the latest Firefox beta (96.0). After using this version for a few days after switching back to ProMotion and watching various YouTube videos, haven't had a single instance of the WindowServer CPU issue.

(In reply to Joshua from comment #92)

It would /appear/ that this has been fixed in the latest Firefox beta (96.0). After using this version for a few days after switching back to ProMotion and watching various YouTube videos, haven't had a single instance of the WindowServer CPU issue.

The feature in question was disabled for release builds as of the latest Fx96 RC build (bug 1748221).

it seems the issue is really fixed with 96.0 beta. So far the problem did not reappear.

We ship release candidate builds to the beta channel. See comment 93.

Attachment #9258376 - Attachment description: WIP: Bug 1738926: Stop enqueueing video when the layer gets overwhelmed. → WIP: Bug 1738926 Part 2: Stop enqueueing video when the layer gets overwhelmed.

The patch seems to work for me. Would you please use the test build and set the pref gfx.core-animation.specialize-video to true and test again?

Flags: needinfo?(martin.racak)
Attachment #9258376 - Attachment description: WIP: Bug 1738926 Part 2: Stop enqueueing video when the layer gets overwhelmed. → Bug 1738926 Part 2: Stop enqueueing video when the layer gets overwhelmed.

Unfortunately, I no longer have access to the hardware (MacBookPro16,2) where I experienced the issue, so I won't be able to test fixes anymore.

Flags: needinfo?(martin.racak)

simonk83, you've also confirmed this issue. Would you please try out the test build with the pref gfx.core-animation.specialize-video set to true and see if the problem is fixed for you?

Flags: needinfo?(simonk83)
Depends on: 1748221

(In reply to Brad Werth [:bradwerth] from comment #99)

simonk83, you've also confirmed this issue. Would you please try out the test build with the pref gfx.core-animation.specialize-video set to true and see if the problem is fixed for you?

Brad Werth, I downloaded 97.0b2 and made sure that gfx.core-animation.specialize-video is true but it appears the bug isn't fixed. WindowServer is now back to ~100%.

(In reply to Joshua from comment #100)

Brad Werth, I downloaded 97.0b2 and made sure that gfx.core-animation.specialize-video is true but it appears the bug isn't fixed. WindowServer is now back to ~100%.

Thank you. Would you also please try with the test build? That is the build that may contain a fix.

Flags: needinfo?(jbwzrd213)

(In reply to Brad Werth [:bradwerth] from comment #101)

(In reply to Joshua from comment #100)

Brad Werth, I downloaded 97.0b2 and made sure that gfx.core-animation.specialize-video is true but it appears the bug isn't fixed. WindowServer is now back to ~100%.

Thank you. Would you also please try with the test build? That is the build that may contain a fix.

Ah, perfect. Thanks for the clarification.

Downloaded that test build, switched back to ProMotion (I've been keeping it at 60 hertz since the beta doesn't have a fix yet), and tested a 4k 60fps video (https://www.youtube.com/watch?v=ib6_c6uliLg) for about three minutes and the WindowServer bug didn't pop up. I can do some more testing if you'd like, but it appears to be fixed in that test build.

Flags: needinfo?(jbwzrd213)

(In reply to Joshua from comment #102)

Downloaded that test build, switched back to ProMotion (I've been keeping it at 60 hertz since the beta doesn't have a fix yet), and tested a 4k 60fps video (https://www.youtube.com/watch?v=ib6_c6uliLg) for about three minutes and the WindowServer bug didn't pop up. I can do some more testing if you'd like, but it appears to be fixed in that test build.

Great news, and all we need. We can land this fix with confidence, now. Thank you. Firefox is a community project and we rely upon and appreciate users who find and help us fix bugs. Thank you.

Flags: needinfo?(simonk83)
Pushed by bwerth@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/76456b0d3ac1 Part 2: Stop enqueueing video when the layer gets overwhelmed. r=gfx-reviewers,mstange
Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox97: affected → disabled
status-firefox98: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: