Closed Bug 1404042 Opened 7 years ago Closed 4 months ago

[meta] Poor battery life on OSX with scaled resolution

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Version:
57 Branch
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
Performance Impact low
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox56 --- wontfix
firefox57 - wontfix
firefox58 + wontfix
firefox59 + wontfix
firefox60 + wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix

People

(Reporter: sphilp, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(4 keywords, Whiteboard: [gfx-noted])

Attachments

(4 files)

Notice CPU change after closing a page with animations
84.14 KB, image/png
Details
High CPU usage in Firefox on MacOS
478.10 KB, image/png
Details
FF59 throbber @ 1440x900.png
1.21 MB, image/png
Details
processes_with_threads.png
393.00 KB, image/png
Details
Many users on various online forums have commented on 57's battery life being poor on OSX, some investigation and resolution would be great as it quite severe and negatively effecting perception of the quantum release. One user claims as much as 1-2% usage per minute.
status-firefox57: --- → affected
I wonder if this is the macOS vibrancy thing hitting us. jrmuizel initially expressed concern about this in bug 1377284 comment 32, but we didn't have any concrete data showing that vibrancy was causing increased power usage. Hey igoldan, are you able to reproduce the battery usage problem with the vibrancy build? How does it compare to the build without vibrancy?
Flags: needinfo?(ionut.goldan)
See Also: → 1377284
Could also be animation related, I imagine. [Tracking Requested - why for this release]: see comment 0
tracking-firefox57: --- → ?
See Also: → 1397092
I'm on 57.0b3 and keeping activity monitor open in the background (do we have an about:energy or something I'm not familiar with?). Couple of things I'm seeing that may not be regressions but are a bit odd. Idle usage: Some content processes are consistently 2-5% even though the browser is just sitting idle. I would guess open network connections given I have tabs like gmail, gdocs, hangouts, irccloud, etc. in the affected processes. I had a background tab (an article page) open with some banner ads, discus, and a few gifs on it and that was consistently using ~25% cpu. Closing that tab dropped the cpu usage for that thread to <1% at idle. For whatever reason there are a large number of idle wake up's on one content process, relative to the other 3 (~350 vs 5-10 per) Active usage: I'm seeing really high (>60% cpu) usage while scrolling Youtube media playback is consistently around 20% cpu after initial page load, scrubbing through the video hits ~60-70% for a couple of seconds and then settles back down That article page with ads and gifs jumped to about 40-50% cpu usage
Did we test Stylo vs. non-Stylo builds?
It'd be good to pinpoint / discard stylo builds, yeah. Also, maybe if Julian is interested he can profile and see where CPU is spent when we're supposed to be idle? He's much better than I at that kind of low level profiling stuff :)
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #1) > I wonder if this is the macOS vibrancy thing hitting us. jrmuizel initially > expressed concern about this in bug 1377284 comment 32, but we didn't have > any concrete data showing that vibrancy was causing increased power usage. > > Hey igoldan, are you able to reproduce the battery usage problem with the > vibrancy build? How does it compare to the build without vibrancy? I'm afraid I haven't been able to get comparison data between pre-vibrancy and post-vibrancy builds.
Flags: needinfo?(ionut.goldan)
(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #6) > (In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from > comment #1) > > I wonder if this is the macOS vibrancy thing hitting us. jrmuizel initially > > expressed concern about this in bug 1377284 comment 32, but we didn't have > > any concrete data showing that vibrancy was causing increased power usage. > > > > Hey igoldan, are you able to reproduce the battery usage problem with the > > vibrancy build? How does it compare to the build without vibrancy? > > I'm afraid I haven't been able to get comparison data between pre-vibrancy > and post-vibrancy builds. I don't think we should investigate using pre-vibrancy builds at this point. Here's a current build with vibrancy disabled: https://queue.taskcluster.net/v1/task/cTMoj2ZJQvODXH-c2dz3tg/runs/0/artifacts/public/build/target.dmg
Alternatively, switch to the Light or Dark themes, which don't use vibrancy. I've heard from at least one user on Reddit who was experiencing the battery drain issue that this did not help, but it'd help to get a second data point on that.
Keywords: power
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #8) > Alternatively, switch to the Light or Dark themes, which don't use vibrancy. > > I've heard from at least one user on Reddit who was experiencing the battery > drain issue that this did not help, but it'd help to get a second data point > on that. I have tried this out and seen a slight improvement in battery drainage but can also report that F58 and below uses much much more battery power when compared to Safari.
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #8) > Alternatively, switch to the Light or Dark themes, which don't use vibrancy. > > I've heard from at least one user on Reddit who was experiencing the battery > drain issue that this did not help, but it'd help to get a second data point > on that. I've always used Light, and have at least noticed this issue since 57.0b3, so I don't think that's the whole story.
Do you guys have any idea how can I help out with this issue on QA side? How can I test?
See Also: 1397092 → 1406414
Not that it's an option for our users, but for those that see this, does disabling e10s make a difference?
This bug is pretty generic and it is making it difficult for me to decide whether we should track for 57. As far as the initial comment by Stuart, can you reference where you saw these posts? I saw https://www.reddit.com/r/firefox/comments/72z8ce/firefox_57_is_still_draining_macos_battery_like/ but I haven't seen widespread reports of this. I also would like to know it if being seen across all Mac OS's or particular ones (for instance 10.13). As far as machines, the new Macbook Pro I have (MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)) has pretty bad battery life on its own - so I would interested to see what types of machines people are reporting this issue on. Also Cristina seems willing to test, but probably needs some guidance as to how to help - can someone please help here? Thanks.
Flags: needinfo?(sphilp)
I unfortunately don't have too many more details, merely reporting that I'm seeing mentioned online. Here are quite a few threads just from reddit: https://www.reddit.com/r/firefox/search?q=battery&restrict_sr=on&sort=relevance&t=all Realistically I'm not sure what's doable here but some ideas: I see a lot of references to youtube video playback. afaik, we use vp9 and not h264 on youtube. h264 has hardware acceleration support on OSX and likely uses much less battery if these users are used to Safari. Other users are reporting consistency high cpu usage in general (5-10% even when idle). Not sure what to look at there unless we can run some studies to collect CPU usage on users with various prefs (stylo, e10s, et al.) flipped on and off perhaps.
Flags: needinfo?(sphilp)
Should also note the background throttling work may help here (at least in the idle case I would hope), see bug 1377766
See Also: → 1396481, 1377766
I see Bug 1403412 which indicates we disabled some part of VP9 on Mac for 57. So I wonder if things got better for those watching youtube videos after that backout.
"I know it’s not officially released, so I’m hoping it gets fixed, but FF57 rips through my Mac’s battery life and runs insanely hot on simple JS apps. I still use it daily because it generally works, but there are a few apps I just have to go to Chrome for." "Same here. FF has always performed poorly on my 15” 2015 rMBP, but this made it worse." https://news.ycombinator.com/item?id=15443498
Keywords: regression, regressionwindow-wanted, steps-wanted, testcase-wanted
See Also: → 1407536
(In reply to Stuart Philp :sphilp from comment #14) > I unfortunately don't have too many more details, merely reporting that I'm > seeing mentioned online. Here are quite a few threads just from reddit: > > https://www.reddit.com/r/firefox/ > search?q=battery&restrict_sr=on&sort=relevance&t=all > > Realistically I'm not sure what's doable here but some ideas: > > I see a lot of references to youtube video playback. afaik, we use vp9 and > not h264 on youtube. h264 has hardware acceleration support on OSX and > likely uses much less battery if these users are used to Safari. As Marcia mentioned, this is no longer the case following bug 1403412. Mac will now by default only ever get H264 (which is hardware accelerated) when watching YouTube
Priority: -- → P2
Marking as blocking for 57, we should do some profiling to figure out what's going on.
tracking-firefox57: ? → blocking
If you're seeing this in 57, please try testing with 'layout.css.servo.enabled' set to false. (restart required when changing the pref)
The other thing I will mention, although not 57 specific, is that Firefox Nightly shows as "Using Significant Energy" when you click on the Mac battery icon.
(In reply to Jim Mathies [:jimm] from comment #21) > If you're seeing this in 57, please try testing with > 'layout.css.servo.enabled' set to false. (restart required when changing the > pref) I just went to do that in 57, and noticed that mine was already set to false. I also just turned the pref to false in nightly and will report back.
I have the pref off in both Nightly and Beta, and I don't really notice much improvement in the battery life. This morning after a full charge I am already down to 66% on my Mac laptop. Both of my browsers have Gmail and bugzilla active, and not many tabs open in each.
In bug 1400787, :kaku conducted a series of experiment, and determined that the issue was most likely in the compositor.
See Also: → 1400787
(In reply to Jean-Yves Avenard [:jya] from comment #25) > In bug 1400787, :kaku conducted a series of experiment, and determined that > the issue was most likely in the compositor. In my case I don't have any YouTube or Netflix or video instances open when I am experiencing this.
(In reply to Marcia Knous [:marcia - use ni] from comment #26) > In my case I don't have any YouTube or Netflix or video instances open when > I am experiencing this. sure... but the issue is likely still be there, regardless of you playing a video or not (we had originally assumed the issue was due to having a video decoder active)
FWIW, I see something like this on my home machine (0.5714 %/min battery loss) when "vibrancy" is on (and not doing anything terribly demanding of the browser) on 58; but disabling "vibrancy" only changes it to 0.5555 %/min.
Marcia could you get a profile next time you see this?
Flags: needinfo?(mozillamarcia.knous)
This bug isn't actionable as it stands. A longer term solution is underway in bug 1265824, but not in the 57 timeframe. I recommend not tracking this bug for 57.
(In reply to Selena Deckelmann :selenamarie :selena use ni? pronoun: she from comment #30) > This bug isn't actionable as it stands. A longer term solution is underway > in bug 1265824, but not in the 57 timeframe. If the solution is bug 1265824, that implies that there has been no regression. Am I correct in that understanding?
I've been experiencing the same battery drain problem for a few weeks, since updating to version 57. With YouTube playing, it can drain my whole battery in less than one hour. FWIW, switching back to version 56 did not improve energy consumption, though the battery usage was fine just a month ago using version 56. Here is a profile, with just two tabs opened (this one and 'Reporting a Performance Problem', so no video, no audio playing), when I scroll/switch tabs: https://perf-html.io/public/0e1189ae63246319c694df54b9e95ceafb0f9e77/calltree/ Another one, simply opening Google and searching for Firefox: https://perf-html.io/public/b0605e557a29e0c22da485ee4cf80085ad0af488/calltree/ In activity monitor, Firefox quickly goes over 100 in 'Energy Impact' in the first profile, and over 300 in the second. Sometimes the system even starts my laptop fan as a result, with no other tabs opened. If I can help with more testing, feel free to ask.
Component: Untriaged → General
Product: Firefox → Core
(In reply to gggdomi from comment #32) > I've been experiencing the same battery drain problem for a few weeks, since > updating to version 57. With YouTube playing, it can drain my whole battery > in less than one hour. > FWIW, switching back to version 56 did not improve energy consumption, > though the battery usage was fine just a month ago using version 56. > > Here is a profile, with just two tabs opened (this one and 'Reporting a > Performance Problem', so no video, no audio playing), when I scroll/switch > tabs: > https://perf-html.io/public/0e1189ae63246319c694df54b9e95ceafb0f9e77/ > calltree/ My (probably uninformed) reading of this indicates Firefox isn't doing much. Is there a way to get a whole system profile of energy usage on macOS? I think njn may know how to do that.
Flags: needinfo?(n.nethercote)
(In reply to Andrew Overholt [:overholt] from comment #33) > My (probably uninformed) reading of this indicates Firefox isn't doing much. > Is there a way to get a whole system profile of energy usage on macOS? I > think njn may know how to do that. That's a solid read - the threads being profiled here are mostly idle. That doesn't mean that there isn't some other thread somewhere that's doing a lot of work and burning battery. If it's YouTube related, I wonder if k17e has some ideas on diagnostic steps we could follow?
Flags: needinfo?(ajones)
Everything I know about power profiling is documented in the "Power profiling" section of https://developer.mozilla.org/en-US/docs/Mozilla/Performance The "Power profiling overview" section is worth reading for anyone interested in power profiling. The Mac tools are described in the "tools/power/rapl", "powermetrics" and "Activity Monitor, Battery Status Menu and top" sections.
Flags: needinfo?(n.nethercote)
Flags: needinfo?(sdeckelmann)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #31) > (In reply to Selena Deckelmann :selenamarie :selena use ni? pronoun: she > from comment #30) > > This bug isn't actionable as it stands. A longer term solution is underway > > in bug 1265824, but not in the 57 timeframe. > > If the solution is bug 1265824, that implies that there has been no > regression. Am I correct in that understanding? Well, I think we're not 100% certain, but we are pretty sure that the work in bug 1265824 will resolve some big issues we have identified. I don't think we should block 57 on this bug, however. NI'ing Ritu to suggest we remove the blocker.
Flags: needinfo?(sdeckelmann) → needinfo?(rkothari)
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #34) > (In reply to Andrew Overholt [:overholt] from comment #33) > > My (probably uninformed) reading of this indicates Firefox isn't doing much. > > Is there a way to get a whole system profile of energy usage on macOS? I > > think njn may know how to do that. > > That's a solid read - the threads being profiled here are mostly idle. > > That doesn't mean that there isn't some other thread somewhere that's doing > a lot of work and burning battery. > > If it's YouTube related, I wonder if k17e has some ideas on diagnostic steps > we could follow? I agree, the profile looks quite flat. Still, as stated, their was high reported 'Energy impact' in Firefox at the time of the profiling - for what it's worth. Right now the 'Average Energy Impact' over the last few hours for Firefox is 249, way beyond any other app (I didn't spent much time on YouTube, but had audio playing). And my very unscientific observations during the last weeks are that my laptop overheat and dramatically loose autonomy when Firefox is running, sometimes even if no audio or video is playing. Moreover, quitting it is enough to have the temperature go down to normal levels after a couple minutes. But well, I'm aware that this testimony is not enough to figure out what's happening. I will read about power profiling on mac and try to provide more meaningful reports in the coming days.
See Also: → 1409166
See Also: → 1410577
(In reply to Stuart Philp :sphilp from comment #3) > I'm on 57.0b3 and keeping activity monitor open in the background (do we > have an about:energy or something I'm not familiar with?). Couple of things > I'm seeing that may not be regressions but are a bit odd. > > Idle usage: > > Some content processes are consistently 2-5% even though the browser is just > sitting idle. I would guess open network connections given I have tabs like > gmail, gdocs, hangouts, irccloud, etc. in the affected processes. > > I had a background tab (an article page) open with some banner ads, discus, > and a few gifs on it and that was consistently using ~25% cpu. Closing that > tab dropped the cpu usage for that thread to <1% at idle. > > For whatever reason there are a large number of idle wake up's on one > content process, relative to the other 3 (~350 vs 5-10 per) > > Active usage: > > I'm seeing really high (>60% cpu) usage while scrolling > > Youtube media playback is consistently around 20% cpu after initial page > load, scrubbing through the video hits ~60-70% for a couple of seconds and > then settles back down > > That article page with ads and gifs jumped to about 40-50% cpu usage Report, could you check about:performance page if the problem happenes again?
Flags: needinfo?(sphilp)
(In reply to Panos Astithas [:past] (please ni?) from comment #29) > Marcia could you get a profile next time you see this? I can try, but during my work day I am running lots of browsers. I may have to try on the weekend when I have more time. In my case I am not running YouTube at all, and I am still burning through battery using a MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports). But this machine has not had great battery life since I got it. Other users might be running on different hardware. I agree with Comment 36 that this shouldn't block 57 unless we are able to isolate the issue. I will read through https://developer.mozilla.org/en-US/docs/Mozilla/Performance and see if I can provide something more useful from my machine.
Flags: needinfo?(mozillamarcia.knous)
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #34) > If it's YouTube related, I wonder if k17e has some ideas on diagnostic steps > we could follow? My 2012 Macbook Air is good on battery except when I use VP9 on YouTube or use WebRTC. I'm assuming bug 1265824 will help. In the meanwhile we've disabled VP9 support in MSE. You can use the Intel Power Gadget if you're not engaging the discrete GPU.
Flags: needinfo?(ajones)
Thanks Selena. Based on the investigation so far this may not be as widespread as I had though. Removing the blocking tracking flag.
tracking-firefox57: blocking → +
Flags: needinfo?(rkothari)
Flags: needinfo?(sphilp)
Per email discussion, won't fixing this for 57 and moving tracking to 58.
status-firefox57: affected → wontfix
status-firefox58: --- → affected
tracking-firefox57: + → -
tracking-firefox58: --- → +
This profile may be more useful than the previous one, there seems to be some activity: https://perf-html.io/public/ac800f46ded8637a75c6b3057bc42af846f1fa25/calltree/?hiddenThreads=&thread=0&threadOrder=0-2-3-4-5-1&v=2 Context: my computer was sitting idle on my desk. I come back after around half an hour, the fans are on, 30% of battery are gone. Huge 'Energy Impact' in Activity monitor (instant and average) for Firefox, almost nothing else running. A couple tabs containing text are loaded since one hour ago, some more tabs are there but not loaded (previous session restored but not activated since restarting Firefox).
(In reply to gggdomi from comment #43) > This profile may be more useful than the previous one, there seems to be > some activity: > https://perf-html.io/public/ac800f46ded8637a75c6b3057bc42af846f1fa25/ > calltree/?hiddenThreads=&thread=0&threadOrder=0-2-3-4-5-1&v=2 > > Context: my computer was sitting idle on my desk. I come back after around > half an hour, the fans are on, 30% of battery are gone. Huge 'Energy Impact' > in Activity monitor (instant and average) for Firefox, almost nothing else > running. A couple tabs containing text are loaded since one hour ago, some > more tabs are there but not loaded (previous session restored but not > activated since restarting Firefox). That profile doesn't seem to contain anything useful. It's possible there's a thread that's not being profiled that's using the CPU. Do you think you'd be able to get a profile using Instruments the next time it happens.
Depends on: 1414943
See Also: → 1414876
(In reply to Dão Gottwald [::dao] from comment #7) > (In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #6) > > (In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from > > comment #1) > > > I wonder if this is the macOS vibrancy thing hitting us. jrmuizel initially > > > expressed concern about this in bug 1377284 comment 32, but we didn't have > > > any concrete data showing that vibrancy was causing increased power usage. > > > > > > Hey igoldan, are you able to reproduce the battery usage problem with the > > > vibrancy build? How does it compare to the build without vibrancy? > > > > I'm afraid I haven't been able to get comparison data between pre-vibrancy > > and post-vibrancy builds. > > I don't think we should investigate using pre-vibrancy builds at this point. > Here's a current build with vibrancy disabled: > https://queue.taskcluster.net/v1/task/cTMoj2ZJQvODXH-c2dz3tg/runs/0/ > artifacts/public/build/target.dmg I've only skimmed through this bug, but I wanted to mention that one can also just use the dark theme on current builds; it does not use the vibrancy effect.
I can confirm this bug. Only few tabs opened and after a while my MacBookPro start warming up, you can hear the CPU fans and when you open the Activity monitor you can see that Firefox use 60% of CPU constantly.
I'm seeing reports of Mac users getting software decoding for videos and seeing excessive cpu. If anyone is seeing this while playing video, it would be useful to know.
Watching YouTube causes my CPU temp to shoot up to 70C, and definitely seems to consume a lot of energy, though I haven't done any measurements. How do I check if it's using software decoding?
(In reply to Nihanth Subramanya [:nhnt11] from comment #48) > Watching YouTube causes my CPU temp to shoot up to 70C, and definitely seems > to consume a lot of energy, though I haven't done any measurements. How do I > check if it's using software decoding? You can install this add-on: https://addons.mozilla.org/en-US/android/addon/devtools-media-panel/ Open devtools and go to the media panel. Then if you reload YouTube I think it will print out a bunch of debugging info. You can copy/paste that here. Getting the text from about:support page would also be useful. But you should probably put that in bug 1418510 for now.
I have a suspicion here. I'm using a Mid 2014 Retina MacBook Pro with Intel graphics and I noted that the CPU usage is much higher when I'm running the screen at a the scaled resolution other than the default 1280x800 (e.g. 1680x1050 aka "More Space" in the macOS display settings). If it was related to display scaling that might explain the trouble people have with reproducing this issue.
(In reply to raphael.kimmig from comment #50) > I have a suspicion here. I'm using a Mid 2014 Retina MacBook Pro with Intel > graphics and I noted that the CPU usage is much higher when I'm running the > screen at a the scaled resolution other than the default 1280x800 (e.g. > 1680x1050 aka "More Space" in the macOS display settings). If it was related > to display scaling that might explain the trouble people have with > reproducing this issue. I think this makes some sense so I did a quick test with an instagram video and 2 macbooks running OS 10.13.1 with Intel graphics. The Mid-2015 Retina Macbook Pro at a scaled resolution (more space) had an increase in the cpu usage and the fans spinning immediately. Also, the video kept stopping and starting. The Mid-2011 Macbook Air (native resolution) barely even phased the CPU and the video played smoothly multiple times.
Thanks Raphael and Christopher, this seems very helpful. Preliminarily moving to Graphics based on comment 50 and comment 51.
Severity: normal → major
Component: General → Graphics
I have done the same test using MacbookAir vs MacBookPro retina, but I haven't seen such significant difference in behavior between those two. But I do believe it is graphics related, it looks to me that it occurs more often on sites with HTML5 animated banners, JS carousels etc. (In reply to Dão Gottwald [::dao] from comment #52) > Thanks Raphael and Christopher, this seems very helpful. Preliminarily > moving to Graphics based on comment 50 and comment 51.
I can reproduce worse performance and higher CPU usage with screen scaling on in my macbook pro 2016 touchbar. With display scaling enabled: https://perfht.ml/2jSAFf6 With display scaling disabled: https://perfht.ml/2jVfg56 This was taken scrolling down on: https://w3c.github.io/ServiceWorker/ Some jank in both cases, but definitely worse with scaling enabled.
Keywords: steps-wanted, testcase-wanted
Summary: Poor battery life on OSX → Poor battery life on OSX with scaled resolution
Hey mstange - do you see anything actionable in the profiles in comment 54?
Flags: needinfo?(mstange)
I personally can confirm that changing the resolution in the settings from More Space to Default brings down CPU usage from 50-60% in idle to 1% and videos/animations doesn't instantly heat up my Mac anymore. Hope it get fixed soon.
(In reply to Ben Kelly [:bkelly] from comment #54) > This was taken scrolling down on: > > https://w3c.github.io/ServiceWorker/ > > Some jank in both cases, but definitely worse with scaling enabled. Hey bkelly, are you able to reproduce higher CPU usage when idle in that configuration? If so, can we get an idle profile from you, sampling all threads? And if that doesn't illuminate anything, we might need you to capture the profile using Instruments, to see if we're causing high CPU usage elsewhere in the underlying OS.
Flags: needinfo?(bkelly)
mstange and I looked at the profiles in comment 54 today in Episode 15 of The Joy of Profiling: https://air.mozilla.org/the-joy-of-profiling-episode-15/
See Also: → 941095
I can't reproduce increased idle CPU usage on my machine. I think it probably depends on what sites you have open when "idle". The display scaling seems to increase the cost of any painting that might be going on. I get the feeling the long term solution here is webrender.
Flags: needinfo?(bkelly)
(In reply to Ben Kelly [:bkelly] from comment #59) > I get the feeling the long term solution here is webrender. We've been here before but this answer still seems too simplistic / misses part of the picture. Why do so many people report this problem only recently? Presumably something regressed here. Could you try to find a regression range?
Flags: needinfo?(bkelly)
(In reply to Dão Gottwald [::dao] from comment #60) > Why do so many people report this problem only > recently? Presumably something regressed here. Could you try to find a > regression range? There is a huge hype around Quantum release, lots of people are trying Firefox for the first time and some of us are getting back to Firefox and want Quantum to succeed. That might be the reason why so many people report energy consumption on macOS now.
There is definitely a regression somewhere in the compositor,one that forded us to disable the vp9 software decoder so that only the h264 hardware one is used. Now, obviously this would only affect battery life during video playback. Someone also mentionee that using the dark theme also made a big difference because some effects aren't in use.
I think the graphics team should investigate and determine if a regression happened. Moving NI to Milan. For what its worth, I've experienced and reported slow graphics on my macbook for at least 6 months. For example, see bug 1365823.
Flags: needinfo?(bkelly) → needinfo?(milan)
Since this bug seems to be focusing on screen scaling issues I split the theme vibrancy off into bug 1420638.
(In reply to Ben Kelly [:bkelly] from comment #49) > (In reply to Nihanth Subramanya [:nhnt11] from comment #48) > > Watching YouTube causes my CPU temp to shoot up to 70C, and definitely seems > > to consume a lot of energy, though I haven't done any measurements. How do I > > check if it's using software decoding? > > You can install this add-on: > > https://addons.mozilla.org/en-US/android/addon/devtools-media-panel/ > > Open devtools and go to the media panel. Then if you reload YouTube I think > it will print out a bunch of debugging info. You can copy/paste that here. > > Getting the text from about:support page would also be useful. > > But you should probably put that in bug 1418510 for now. I missed this comment :( I installed the add-on and it seems like hardware decoding is being used. Here's the debugInfo block in case it's useful: debugInfo : { Container Type : "MediaSource" Audio Decoder(audio/opus) : "opus audio decoder" Audio Frames Decoded : "232" Audio State : "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=232 out=232 qs=0 pending=0 wfd=0 eos=0 ds=0 wfk=0 sid=0" Video Decoder(video/avc, 1920x1080 @ 60.00) : "apple hardware VT decoder" Hardware Video Decoding : "enabled" Video Frames Decoded : "168 (skipped=0)" Video State : "ni=0 no=1 wp=0 demuxr=0 demuxq=0 decoder=1 tt=-1.0 tths=-1 in=173 out=168 qs=5 pending:0 wfd=0 eos=0 ds=0 wfk=0 sid=1" Dumping Data for Demuxer : "122ec7400" Dumping Audio Track Buffer(audio/webm) : "mLastAudioTime=4.641000" Audio Track Buffer Details : "NumSamples=1500 Size=1001629 Evictable=158736 NextGetSampleIndex=232 NextInsertionIndex=1500" Audio Track Buffered : "ranges=[(0.000000, 30.001000)]" Dumping Video Track Buffer(video/mp4) : "mLastVideoTime=2.883333" Video Track Buffer Details : "NumSamples=1520 Size=10321583 Evictable=0 NextGetSampleIndex=173 NextInsertionIndex=1520" Video Track Buffered : "ranges=[(0.000000, 25.333333)]" MediaDecoder=12325a600 : "channels=2 rate=48000 hasAudio=1 hasVideo=1 mPlayState=PLAYING" MDSM : "duration=1594821000 GetMediaTime=2623875 GetClock=2635479 mMediaSink=12306a660 state=DECODING mPlayState=3 mSentFirstFrameLoadedEvent=1 IsPlaying=1 mAudioStatus=idle mVideoStatus=pending mDecodedAudioEndTime=4634500 mDecodedVideoEndTime=2800000 mAudioCompleted=0 mVideoCompleted=0 mIsPrerolling=0" VideoSink : "IsStarted=1 IsPlaying=1 VideoQueue(finished=0 size=10) mVideoFrameEndTime=2650000 mHasVideo=1 mVideoSinkEndRequest.Exists()=0 mEndPromiseHolder.IsEmpty()=0" AudioSinkWrapper : "IsStarted=1 IsPlaying=1 AudioEnded=0" }
Experiencing high CPU issue in a Early 2015 Macbook pro as well Now running High Sierra, before Sierra (issues on Sierra are the same) Model Name: MacBook Pro Model Identifier: MacBookPro12,1 Processor Name: Intel Core i5 Processor Speed: 2.7 GHz Number of Processors: 1 Total Number of Cores: 2 The persists between beta and nightly. Display scaling doesn't seem to have any effect. Opening new tab, scrolling seem to be affected. Doesn't seem like the website matters. The overall experience is sluggish and firefox is constantly between 30% to 115% cpu. Anything else I can contribute to the issue will gladly do.
Aleksandr, can you install the addon here: https://perf-html.io/ And capture a profile of your scrolling CPU usage? More info on using the profiler addon is on this page if its not self-explanatory: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
Flags: needinfo?(gulyayev.alex)
Ben is https://perfht.ml/2BdLzQ2 of any use? From Mid-2015 MacBook Pro 13" with High Sierra. I always have this is scaled mode all the way to the right (More Space). I was accessing Amazon.com scrolling deal carousels and changing deal categories.
Here is mine https://perfht.ml/2A7P2Tp MacBook Pro 13" Hight Sierra, Dark firefox theme, no extensions: Steps to reproduce: - Open Firefox - Navigate to nytimes.com - Not even scrolling, just leave it that way with opened NY Times homepage CPU usage of FirefoxCP WebContent >100% while rendering and after rendering constantly >60% plus usage of Firefox process
Whiteboard: [gfx-noted]
(In reply to Brian Lyttle from comment #68) > Ben is https://perfht.ml/2BdLzQ2 of any use? From Mid-2015 MacBook Pro 13" > with High Sierra. I always have this is scaled mode all the way to the right > (More Space). I was accessing Amazon.com scrolling deal carousels and > changing deal categories. Thanks. It seems to be spending time in painting, but I will defer to graphics folks to analyze that. (In reply to Miloš Milleusnić from comment #69) > Here is mine https://perfht.ml/2A7P2Tp MacBook Pro 13" Hight Sierra, Dark > firefox theme, no extensions: > > Steps to reproduce: > - Open Firefox > - Navigate to nytimes.com > - Not even scrolling, just leave it that way with opened NY Times homepage > > CPU usage of FirefoxCP WebContent >100% while rendering and after rendering > constantly >60% plus usage of Firefox process This is painting a lot. Its possible this is due to an animation on the page. Maybe you are hitting something like bug 1419079 and the screen scaling is just making it worse.
(In reply to Ben Kelly [:bkelly] from comment #70) > (In reply to Brian Lyttle from comment #68) > > Ben is https://perfht.ml/2BdLzQ2 of any use? From Mid-2015 MacBook Pro 13" > > with High Sierra. I always have this is scaled mode all the way to the right > > (More Space). I was accessing Amazon.com scrolling deal carousels and > > changing deal categories. > > Thanks. It seems to be spending time in painting, but I will defer to > graphics folks to analyze that. > > (In reply to Miloš Milleusnić from comment #69) > > Here is mine https://perfht.ml/2A7P2Tp MacBook Pro 13" Hight Sierra, Dark > > firefox theme, no extensions: > > > > Steps to reproduce: > > - Open Firefox > > - Navigate to nytimes.com > > - Not even scrolling, just leave it that way with opened NY Times homepage > > > > CPU usage of FirefoxCP WebContent >100% while rendering and after rendering > > constantly >60% plus usage of Firefox process > > This is painting a lot. Its possible this is due to an animation on the > page. Maybe you are hitting something like bug 1419079 and the screen > scaling is just making it worse. I forgot to mention that I run MacBookPro 2016 with default screen settings (retina). There is only large AdSense animated banner on screen (as well as on many other websites worldwide) and news images are rotating and that is it. You can see the screenshot on this link https://pasteboard.co/GVCChzy.png I hope that profiles will help in solving the problem.
I am also having much higher CPU usage and lots of dropped frames in scrolling, when using scaled resolution. But I wonder if it is due to scaling or merely more pixels to paint. If I keep the same window size, the performance seems to be about the same, whereas on an external display with 4k non-scaled resolution, it is even worse. I've collected profiles for these cases, with right this webpage: https://bugzilla.mozilla.org/show_bug.cgi?id=1404042. But it is similar with all webpages: 1. 2560x1600 maximized window https://perfht.ml/2jqgWPO 2. 3360x2100(scaled) same window size as 1 https://perfht.ml/2jqXN0s 3. 3360x2100(scaled) maximized window https://perfht.ml/2jqGZqg 4. 3840x2160(ext) same window size as 1 https://perfht.ml/2jsntJZ 5. 3840x2160(ext) maximized window https://perfht.ml/2jsnzBx These are taken on Firefox 58.0b6 running on an early-2015 MacBook Pro with Intel Iris 6100 graphics. Maybe this chip is just too weak for ~4k resolution but in the meantime Safari and Chrome have no dicernable performance drop with the larger resolutions.
A recurring theme from the profiles that I'm seeing in this bug is frequent compositing on the compositor thread.
Yet another High Sierra MBP Early15 13' https://perfht.ml/2n6xUYA Just scrolling up and down on non-js heavy website.
Flags: needinfo?(gulyayev.alex)
Blocks: 1420699
Flags: needinfo?(milan) → needinfo?(jmuizelaar)
So from reading this bug it's unclear to me if there's any regression. Does anybody have a situation where they see high CPU usage in 57 but not in 56?
Flags: needinfo?(jmuizelaar)
Not using scaled resolution, but the switch from 56->57 disabled 5-6 of the addons I was using that were blocking e10s, and e10s has certainly caused performance issues and battery drain.
Please, stay on topic. I do not experience the bug on my Marcos, but I track a lot of user forums and definitely there is a sharp increase in reports from *old* users (i.e. ones using Firefox prior to 57) about Firefox draining a lot of energy and spinning CPU to 100% on not heavy websites starting with 57. So, my best understanding is that there is one or more regressions in 57 that affect Mac users. Scaling and videos show up disproportionally often in the reports but I'm not sure if they're necessary to reproduce because some users report high battery drain on Mac is.without external monitor.or video playing. While the affected population may be small, the severity of the problem is high as it basically blocks those users from using Firefox.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #77) > Please, stay on topic. > > I do not experience the bug on my Marcos, but I track a lot of user forums > and definitely there is a sharp increase in reports from *old* users (i.e. > ones using Firefox prior to 57) about Firefox draining a lot of energy and > spinning CPU to 100% on not heavy websites starting with 57. Are we certain those users were using e10s before 57?
Flags: needinfo?(gandalf)
:Cam, apologies for my remark. I did not understand your comment - now I see it was on topic. Jeff - I'll poll affected users and try to give you an answer, but it may take a couple days to get the anecdotal answers here.
It seems likely 59 is also affected here. Tracking in the hopes that it may be possible to figure out this issue in the 59 timeframe.
status-firefox59: --- → affected
tracking-firefox59: --- → +
I posted to r/firefox [0] and will work with the community on collecting the outcome and will summarize it soon in this bug. [0] https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/
Depends on: 1421638
One thing that I've noticed is that off-screen tab throbber animations cause more CPU usage than the old APNG throbbers. I believe bug 1419096 and bug 1419079 should help with that.
Depends on: 1419096, 1419079
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #81) > I posted to r/firefox [0] and will work with the community on collecting the > outcome and will summarize it soon in this bug. > > [0] > https://www.reddit.com/r/firefox/comments/7g6k9n/ > firefox_quantum_is_eating_your_cpu_help_us_debug/ Is this not a different issue? I thought this one was about higher than expected cpu usage when scrolling on simple websites. Mine stays between 30% and 60% consistently when using.
> Is this not a different issue? Different from what? The title of this bug states "Poor battery life on OSX with scaled resolution". I'm trying to investigate if it's a regression from 56 and/if it's related to e10s enabling as per comment 78.
I wonder if this sheds any light on anything, or if anyone can replicate my experience. Firefox on my 13" 2013 retina MBP Core i5 / Iris / MacOS 10.13.1 puts massive strain on the GPU when the Firefox window is frontmost and Firefox is animating or scrolling. The CPU load is moderate ~70% (out of 400% max). iStat Menus tells me the GPU is drawing ~15 Watts and the CPU ~4 Watts. With Chrome and Safari the same site has the GPU ~3 Watts. I think it's the GPU load which spins the fan up, not the CPU load. I can't replicate this high GPU load on my old WhiteBook with Core2Duo and 10.12.4 so I don't know whether it's just my Mac, or just 10.13, or whatever. Can anyone else replicate high GPU loads on https://codepen.io/davidhc/pen/nLpJk with a setup similar to mine? You could use iStat Menus and look at the GPU die power consumption, or use System Information > Battery > Amperage with the charger disconnected and cmd-R for a couple of minutes to get the correct current draw. Any recent version of Firefox, 57 and 59 both have the same problem for me. Then compare with Safari and/or Chrome. My Mac at half brightness and running Firefox draws ~2500 mA or ~30 Watts to run that animation, Chrome and Safari ~10 W. I definitely have a very poor battery life with Firefox. - a couple of hours if I scroll and animate a lot. Now I know why. Scaling doesn't seem to affect much.
I can confirm that with https://codepen.io/davidhc/pen/nLpJk open and a similar setup, my CPU goes nuts. As soon as I close the page and return to a page with fewer changes, things start to slow cool down a little. I'm going to attach a screenshot.
Jeff, any thoughts on comment 85?
Flags: needinfo?(jmuizelaar)
(In reply to Ben Kelly [:bkelly] from comment #89) > Jeff, any thoughts on comment 85? That comment says "Scaling doesn't seem to affect much" so it seems like it should be filed as a separate bug.
Flags: needinfo?(jmuizelaar)
Re Comment 90, Jeff, point taken, I'll file a new bug tomorrow.
(In reply to Mark from comment #91) > Re Comment 90, Jeff, point taken, I'll file a new bug tomorrow. I'll clone a bug right now.
Now that's service :)
Maybe some of you guys are having the same problem as me:- high GPU (G for George) power consumption when Firefox is showing moving/scrolling images at high Retina resolutions. I put a long boring post on bug 1422090 comment 12 about this if you want to see what I found. If you were having the same problems as me it would explain a lot of what's on this thread:- hot Mac + short battery life when using Firefox to scroll/animate/watch videos at high Retina resolutions. My experience with my MacBookPro11,1 is that stressing the CPU alone does not make the fan become audible. I think I understand why this is & can explain if anyone is interested. If your fan(s) are becoming loud, it may mean that the GPU (G for George) is being stressed, like mine is. If anyone has a scientific mind and wants to spend half an hour replicating what I did it would be great to hear your results. In particular, does the high GPU (G for George) power consumption occur on anyone else's Mac? Does it occur on MacOS versions prior to 10.13? What about integrated vs discrete graphics? I wonder if this is a MacOS 10.13 issue? It seems like people have only been complaining recently, and I don't think it's a Firefox regression. Workarounds for me are - open Firefox in Low Resolution mode https://support.apple.com/en-us/HT202471 - keep Firefox windows small, e.g. less than 60% of display width - don't run Mac at very high Retina resolutions, e.g. use Default Retina resolution On my Retina MBP, these reduce the GPU (G for George) power consumption somewhat and increase my battery life, but it's still not as good as Safari. And it makes Firefox a bit blurry. Of course, maybe I'm the only one with this problem ;) !
Bug seems to be gone in Firefox 58.0b8. I don't know it's because I have had my MacBookPro11,2's top case (including battery) replaced, but probably not related.
Performance is slightly better on 58.0b9 than on 59 nightly and 57 stable. Still firefox processes shoot to > 100% cpu on simple websites, around 30% - 60% when scrolling. CPU is not actively consumed when firefox is in the background. I am not using scaling on my MBP, default resolution.
Seems there are a few separate issues at hand: - Over 100% cpu usage consistently - Abnormally high CPU usage during rendering and scrolling - Abnormally high CPU usage when rendering specific websites Are there tickets for each of these, or is this a bundle of them altogether?
I also have this issue. FF 57 works really great sometimes, but it starts to boil my computer some other times. Macbook Pro mid-2015, 15", the highest upscaled screen resolution. I can technically do some tests if necessary. I applied the default resolution and the CPU is at only ~2-4% instead of 30-40%. I guess this is related.
Edit: I'm using 58ß10.
Re Comment 98 We have a test case on bug 1422090 which causes my MacBook Pro 13" with integrated graphics & MacOS 10.13.2 to get warm & spin up its fan. I wonder if you could try it and tell us about Mac temperature, fan noise, battery consumption. Could you try this:- - set your Mac to 1440x900 resolution and 50% brightness - open a Firefox window and drag it to fill the whole screen. 58b10 is fine. - make sure the Firefox window is at the front, with no other windows covering it up - unplug your Mac from the charger and note the battery % - navigate to this page https://codepen.io/davidhc/pen/nLpJk - make sure the animation at the bottom of the screen is running, fading between pictures - leave the animation running and watch it and answer these questions (1) after a few minutes can you hear the fans in a quiet room? after 1 minute? 5 minutes? 10 minutes? (2) after a few minutes does your Mac get quite warm? (3) after 10 minutes, check the battery %. How much % was used in 10 minutes? (4) what version of MacOS are you running? Thanks
Re Comment 100 Hey Mark. Here are the results from the tests I've made: Using: - 1440x900 (default resolution); - Screen at 50% brightness; - Keyboard at 50% brightness too; - Firefox 58ß10, at fullscreen; - No other windows covering it up (only when I was not looking from iStatsMenus and filling the infos on TextEdit.app); - No second or third display connected of course. Note that I am not using a 13”, but a 15” (MacBook Pro (11,4), Retina, 15-inch, Mid 2015, 2.2 GHz Intel Core i7, Intel Iris Pro w/1536 MB VRAM), under macOS Sierra 10.12.6. Starting at 09:26 (09/12/17): Launched CodePen with Firefox without any addons - Not warm at all - Battery: 70%, 2:57 remaining - CPU: 60°C - Fans are quiet, ~2000rpm (minimum) 09:28 (09/12/17): still on CodePen - Is a little warm - Battery: 69%, 2:27 remaining - CPU: 68°C - Fans are quiet, ~2000-2100rpm (minimum) 09:34 (09/12/17): still on CodePen - Is a little warm - Battery: 66%, 2:08 remaining - CPU: 80°C - Fans are quiet, at ~2000-2100rpm (minimum) 09:36 (09/12/17): still on CodePen - Warmer than before - Battery: 63%, 1:40 remaining - CPU: went up to 94°C (???) for about 15-30 seconds, but now back at 75°C - Fans up at ~3000rpm After this, the fans went down back to “normal” (~70°C), but I was still losing too much battery for a simple CSS animation.
Re Comment 101 Hi Anthony, that's great, thanks so much. I think you have the same problem as me. You have also saved me a lot of work, I was going to spend today checking 10.12.4 but you have done it for me. I think the problem is that Firefox puts the Mac's GPU (G for George) under a lot of strain. So, since it's probably a GPU problem, shall we continue the conversation on the GPU thread at bug 1422090? I will put a link in to your comment 101 and I will make some comments on your post over on that thread? See you there!
ni? to myself to gather a profile on the test MBP with software decoding enabled.
Flags: needinfo?(mconley)
Dan (kamidphish) has a MBP exhibiting the problem even with hardware decoder enabled. Intel power mètre shows over 25W power usage with FF running (but idle) , 4W without. You may want to liaise with him.
Flags: needinfo?(dglastonbury)
Re Comment 103 & comment 104. Check whether Firefox is TRULY idle in Dan's example. For me even the tiniest animation, even the tab bar throbber, causes Firefox's power consumption to do exactly what you describe, ~25 W in Intel Power Gadget vs ~5 W idle. The CPU draws about 7 W and the GPU about 14 W with (presumably) the rest being ancillary components. I'll attach an annotated screen grab showing what I see. I set FF59 up so that it covered the whole screen at 1440x900 and then set a tab loading and switched tabs so that all that was visibly animating on the screen was the FF59 tab bar throbber. Intel Power Gadget says ~25 W vs ~5 W idle. MacBookPro11,1 Intel Iris, MacOS 10.13.2
Hello! Thought I'd chime in here again. I was just in a meeting and had Nightly open with three tabs: my bugzilla to-do's [1] and two Google docs (and twitter every now and then). My battery dropped from 100% to 78% in just over 30 minutes. Nightly's "Avg Energy Impact" in Activity Monitor was 19.53. After closing the Google doc tabs, the energy consumption rate reduced to a 6% drop in the following 20 minutes - which according to my calculations is a factor of ~2.4. This was on my 2-year-old Macbook Pro, with the screen brightness at about 50%, and the display resolution set to "Default for display" - i.e. NOT scaled. [1] https://fitzgen.github.io/bugzilla-todos/
(In reply to Nihanth Subramanya [:nhnt11] from comment #108) > Hello! Thought I'd chime in here again. I was just in a meeting and had > Nightly open with three tabs: my bugzilla to-do's [1] and two Google docs > (and twitter every now and then). My battery dropped from 100% to 78% in > just over 30 minutes. Nightly's "Avg Energy Impact" in Activity Monitor was > 19.53. After closing the Google doc tabs, the energy consumption rate > reduced to a 6% drop in the following 20 minutes - which according to my > calculations is a factor of ~2.4. > > This was on my 2-year-old Macbook Pro, with the screen brightness at about > 50%, and the display resolution set to "Default for display" - i.e. NOT > scaled. > > > [1] https://fitzgen.github.io/bugzilla-todos/ Clarification: by "after closing the Google doc tabs" I actually meant "after transferring the Google docs tabs to a different browser (Safari)"
Re Comment 108, what version of MacOS are you using? Were you actively using the Google docs (scrolling, typing) or were they just sitting completely static for the whole time? cheers
(In reply to Mark from comment #110) > Re Comment 108, what version of MacOS are you using? Were you actively using > the Google docs (scrolling, typing) or were they just sitting completely > static for the whole time? cheers - MacOS High Sierra Version 10.13.1 (17B1003) - The Google docs were sitting static. My only interaction with the browser was opening a tab every now and then for minute-long Twitter sessions.
Mmm, I can't explain that. On my MacBook Pro running 10.13.2 I do see very very very high power consumption when scrolling or typing in a Google doc. I think that's partly vibrancy and partly something to do with CSS animations (see bug 1422090 for both). But for me if the Google doc is completely static (no scrolling, no typing, nothing), power consumption is pretty low, nothing like what you describe. I don't use Twitter, but if has any active CSS animations and you had the Twitter window open for appreciable lengths of time you might be suffering what I suffer in bug 1422090. I thought I understood this power consumption issue, but now I am not so sure ;)
Re Comment 111 and Comment 112 I looked at the Twitter home page. On Firefox it seems to cause the screen to continually refresh at ~50 FPS. This increases my GPU (G for George) power consumption from ~0 W to ~4 W and the total laptop power consumption from about 10 W up to about 20 W. Safari doesn't show this and stays around 10 W. 20 W power consumption is broadly consistent with what you see, a couple of hours battery life. Maybe. twitter.com seems to have a lot of CSS animations, so maybe you are either seeing - a CSS animation throttling problem (animations play even when off the screen) or - bug 1422090 (a sketchy feeling I have that CSS animations cause the graphics processor to have disproportionately high power consumption, possibly only with MacOS 10.13)
Using Firefox 57 & 59 I see twitter.com continuously running at ~40 FPS on 10.13.2, even when it's loaded and "static". I'm looking at Quartz Debug FPS meter. Once I've scrolled down and the swirler has swirled to load all the page content the FPS drops to near zero. My older Mac running 10.12.4 does not do this. Throttling issue? I have no idea.
FWIW here's more from me on my Mac. Sorry for such long posts. I noticed that my CPU was deeply throttled at 1440x900 when using Firefox 57/58/59. That throttling makes Firefox sluggish and it goes to 100% in Activity Monitor just doing mundane tasks like animating, scrolling. Loading a page at 1680x1050 is substantially slower than at 1280x800, I assume because of the throttling. So I think I understand most of what's going on on my Mac. I think it's mostly related to vibrancy (aka transparency) calculations, the load they put on the GPU (G for George), and the knock-on effects on the CPU (C for Charlie). * Some of you might be seeing the same thing?? Basically, when I run Firefox at high resolution, the Intel CPU+GPU package gets so hot it throttles & behaves like a much lower class machine, say a Celeron. I think it goes like this:- 1. MacOS has to calculate vibrancy over every pixel of the Firefox window. When ANYTHING is animating on the Firefox window (even the tab throbber) this puts a lot of demand on the GPU (G for George). Demand means power consumption and heat dissipation:- => hot Mac => loud fans => short battery life 2. As the screen resolution increases, the power & heat demand on the GPU (G for George) increases as well. At some particular resolution one or both of these things happen:- 2a. the GPU (G for George) hits its maximum power and starts to drop frames => janky animations => janky scrolling and/or 2b. the CPU (C for Charlie) has to throttle to keep itself & the whole CPU+GPU package within defined power/heat limits. => Firefox gets sluggish, particularly page loads => Activity Monitor shows 100% when Firefox is doing mundane tasks like scrolling, simple animations. Maybe some of you see the same thing? If you have a discrete GPU perhaps things are different. You can see temps and powers in Intel Power Gadget.
Thanks to everyone for sharing their experiences. I'm going to request that we keep this bug about the scaled resolution issue. If you are seeing high other power consumption on other use cases, such as Google Docs or Twitter, please file a separate bug for each case. It gets very confusing when a lot of people pile onto a single bug, and it makes it hard to understand the history. Thanks!
(In reply to Nicholas Nethercote [:njn] from comment #116) > Thanks to everyone for sharing their experiences. I'm going to request that > we keep this bug about the scaled resolution issue. If you are seeing high > other power consumption on other use cases, such as Google Docs or Twitter, > please file a separate bug for each case. It gets very confusing when a lot > of people pile onto a single bug, and it makes it hard to understand the > history. Thanks! This bug was not originally specific to scaled resolutions and I disagree with the decision to change the bug summary to that effect. I don't see how a scaled resolution alone could be having any effect on energy consumption other than magnifying it. It's intuitive to me that the underlying cause is unlikely to be directly connected to a display resolution setting (though if I'm wrong I will have learned!). I do understand that this bug is getting noisy though :( (In reply to Mark from comment #115) > 1. MacOS has to calculate vibrancy over every pixel of the Firefox window. > When ANYTHING is animating on the Firefox window (even the tab throbber) > this puts a lot of demand on the GPU (G for George). This is an interesting hypothesis. On the one hand I want to disagree with it since I notice high energy consumption with media playback as mentioned earlier in the bug, but on the other hand, maybe I'm wrongly trusting MacOS (and our platform vibrancy implementation) to restrict recalculation to relevant pixels (tabstrip) when things are animating. I'm going to globally disable vibrancy (System Preferences -> Accessibility -> Display -> Reduce transparency) and see if it makes a significant/noticeable difference. Thanks!
re Comment 117 Reduce Transparency doesn't help me. I think it only works on system windows, not user. You can see this if you open a Terminal window, make it transparent in Terminal > Preferences > Text > Background. For me Accessibility > Reduce Transparency has no effect on that Terminal window.
(In reply to Nihanth Subramanya [:nhnt11] from comment #117) > [...] I do understand that this bug is getting noisy though :( It's not clear to me what exactly you're arguing against then. This bug was way too vague and basically stalled until people came along and confirmed that the display resolution setting made a big problem for them. That doesn't mean that there couldn't be other factors contributing to excess power consumption, and those should be tracked, discussed and likely fixed in separate bugs. Use dependencies and meta bugs to connect related issues.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #78) > (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #77) > > Please, stay on topic. > > > > I do not experience the bug on my Marcos, but I track a lot of user forums > > and definitely there is a sharp increase in reports from *old* users (i.e. > > ones using Firefox prior to 57) about Firefox draining a lot of energy and > > spinning CPU to 100% on not heavy websites starting with 57. > > Are we certain those users were using e10s before 57? I'm sorry it took so long, but I now have a solid sample of reports from reddit/r/firefox users to base an answer on. I described the hypothesis and got over 180 comments with many anecdotal reports of users experiencing the high CPU spikes. Based on all reports I could identify as related to the following scenario: 1) User is on 56 and e10s is OFF 2) User switches to 57 and e10s is ON I believe that there's evidence supporting the hypothesis that turning e10s for those users is correlated with the high CPU usage. Here's a sample of reports: 1) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/dqh01u8/ 2) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/dqjemi2/ 3) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/dqny0gd/ 4) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/dqlfi7r/ 5) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/dqnh06a/ 6) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/dr3opdh/ Most of those users were able to verify that turning e10s ON in Firefox 56 causes them to reproduce the spike, several also reported that turning e10s OFF in 57 removes the problem. I only saw one report claiming that they were affected by the problem in 56 with e10s ON: 1) https://www.reddit.com/r/firefox/comments/7g6k9n/firefox_quantum_is_eating_your_cpu_help_us_debug/drdk2pk/ Hope that helps! p.s. I'm now running a follow up experiment asking users to profile Firefox when the problem happens and file a new bug with it: https://www.reddit.com/r/firefox/comments/7knnn4/firefox_quantum_is_eating_your_cpu_help_us_debug/
Flags: needinfo?(gandalf)
Hey jya - we talked about this briefly in Austin, and I'm now coming back to it - do we have reason to believe that a greater proportion of our macOS user population is falling back to software video decoding, and that this is where the battery drain is coming from? Am I articulating that correctly?
Flags: needinfo?(mconley) → needinfo?(jyavenard)
It used to be the case, but we disabled support for VP9 on mac. When VP9 was enabled it would be used by default with YouTube. Now that it is disabled, H264 is used which is by default hardware accelerated except for low resolution and this vary according to the Gpu used. Typically 240p and lower will be using software. We have no control over this. But even with low resolution, people have reported very high power usage. Just moving a lot of pixels appear to be using more power than needed.
Flags: needinfo?(jyavenard)
To summarise, disabling the HW decoder and using a decoder that outputs Yuv software buffer, shows very poor performance and this is much much worse with e10s enabled.
Do we have any idea why it would be worse with e10s disabled?
Flags: needinfo?(jyavenard)
or rather enabled.
No. Just noticed that with e10s disabled ill have no issue playing 60fps videos, they are close to unusable with. Mind you, this isn't limited to mac, I'm seeing the same on Windows even with the hardware decoder. It's just worse on mac
Flags: needinfo?(jyavenard)
Ok, that's surprising. Do you mind splitting that off into a separate issue and investigating why it's worse?
Flags: needinfo?(jyavenard)
There's already one: bug 1409051
Flags: needinfo?(jyavenard)
Could this be the GPU overloading which I saw at high scaled resolutions in bug 1422090? Probably because of the bug 1422090 window transparency issue, my GPU overloads and starts dropping lots of frames when animating at 60 fps & scaled 1680x1050 resolution. I don't know why turning off E10s would fix it, I did some playing with E10s just now and (tentatively??) it does seem to reduce GPU load but I don't understand why. I need to dig more. Could you give me a sample 60fps YouTube video which causes you problems? I might dig into it a bit more, particularly using Jeff's special "non-transparent" Firefox build which has cured a lot of my problems. Also, what kind of Mac were you using? Integrated graphics?
Re comment 126 I don't see a massive difference on a test 60 fps YouTube video between E10s enabled & disabled. I do see a massive difference if I disable hardware acceleration, which I would expect as the CPU works very hard in that case. In the case of hardware acceleration disabled, if I also disable E10s I get some fps performance back, but it's still not as good as the default case E10s enabled && h/w accel enabled. There were some fps differences as long as I kept h/w acceleration enabled it was highly watchable and not "close to unusable". What I did notice is that it takes a surprising amount of GPU power - >5 W - to h/w decode a 60 fps 4K stream. My Mac is struggling to reach 60 fps (see table below) even in the best case scenario. Given that my GPU can only take 20 W, that's around 25% of its capacity. I guess if maybe you are using an ultra-low power platform like a 12" MacBook the GPU (a 5 W part????) may really struggle to decode 60 fps YouTube && do the MacOS transparency upscaling/compositing at the same time. I also ran my "speed scrolling" test again with E10s enabled and disabled and saw better fps with E10s enabled. My guess is YMMV, results will be highly dependent on the Mac's GPU performance. MacBookPro5,5 @1440x900, MacOS 10.13.2, 60 fps demo https://www.youtube.com/watch?v=o9oVbXeBHvM at normal size (not full screen). Firefox window full screen CPU / GPU power from iStat Menus; fps from Quartz debug Nightly 2018-01-04 HW decoding enabled disabled E10S enabled 5 W / 12 W / 40 fps 8 W / 7 W / 25 fps disabled 5 W / 12 W / 50 fps 9 W / 8 W / 40 fps Jeff's special non-transparent build-1 HW decoding enabled disabled E10S enabled 6 W / 12 W / 50 fps 8 W / 6 W / 40 fps disabled 5 W / 10 W / 50 fps 8 W / 8 W / 35 fps Speed scroll mozilla.org Nightly 2018-01-04 E10S enabled 6 W / 14 W / 60 fps disabled 5 W / 14 W / 50 fps Jeff's special non-transparent build-1 E10S enabled 4 W / 4 W / 60 fps disabled 8 W / 4 W / 50 fps
See Also: → 1409051
Mark, how did you select the resolution in YouTube, did you leave it on Auto? If so not going full screen you're going to be getting 480p content typically @ 15 or 30fps Also I wouldn't consider a 25fps VS 40fps as highly watchable, and to me that's a massive difference. especially if you're playing a 60fps stream. More than half the frames dropped! 5W to do 4k @ 60fps sounds very low to me. Most people have reported in excess of 25W on a 15" MBP
Oops, shows I don't use YouTube much. It claims to be running at 1080p & 60 fps by default. I tried some 1440p videos but couldn't get any of them to play at >40 fps even in Safari. I can't find any "real" 4k stuff. So no idea what's going on. Anyway I looked at a few videos and forced them all to 1080p & 60 fps and got much the same results. I tried changing the zoom level of the video and it didn't make much difference. I couldn't run fullscreen because I needed to see iStat Menus. I noodled around with the Mac scaled resolution up to 1680x1050 and the GPU consumption increased overall in line with bug 1422090 but I didn't see any exciting differences between E10s enabled/disabled. I just don't see any big difference between E10s enabled & disabled. I DO see a big difference with h/w accel enabled & disabled, but I'd expect that. I DO see a big difference moving from stock "transparent" Nightly to Jeff's special "opaque" build-1 but again I'd expect that. All I really see is - disabling h/w acceleration offloads the GPU by a few watts and I guess the CPU chokes so the frame rate halves. - moving to opaque build-1 offloads the GPU by a few watts @1440x900 and a LOT of watts @1680x1050 in line with bug 1422090 I think these power values need to be taken with a pinch of salt, they fluctuate a lot so this is Mk I Eyeball averaging. And of course, I'm not trying "real" 4K video but I don't know how. It sounds like we are seeing something very different from each other. I wonder why? Re 5 W vs 25 W, I was trying to break out the h/w accel power consumption on the GPU from the MacOS Quartz transparency/upscaling/compositing on the GPU. I only have a sketchy idea but I think the latter is enormous particularly at high scaled resolutions, partly because Firefox is transparent. That's what bug 1422090 is about. The former is perhaps not so enormous - I guessed 5 W. I agree the total can be huge particularly at 1680x1050. 25 W sounds reasonable. MacBookPro5,5 @1440x900, MacOS 10.13.2, Firefox window fullscreen, https://www.youtube.com/watch?v=jyzexrN0m40 zoomed to 300% (but it doesn't seem to matter much) Nightly 2018-01-04 HW decoding enabled disabled E10S enabled 4 W / 10 W / 60 fps 7 W / 7 W / 30 fps disabled 4 W / 10 W / 60 fps 7 W / 6 W / 30 fps Jeff's special non-transparent build-1 E10S enabled 3 W / 6 W / 60 fps 8 W / 3 W / 30 fps disabled 4 W / 7 W / 60 fps 6 W / 2 W / 30 fps
Ha I just got around to reading bug 1409051 and it sounds like a 4k only issue so you can probably ignore all the waffle I posted in comment 132 etc. I don't have a 4k panel. Sorry.
By default, the YouTube player uses a 640x360 window, if you greatly increase the size of the window it jumps to 1280x720 the player then, if in auto mode will only load content adapted for that size: so 360p or 720p stream. So playing YouTube, https://www.youtube.com/watch?v=jyzexrN0m40 with the default mode gives you: Video ID / CPN jyzexrN0m40 / F8Pc6qSe6vkj3kRe Viewport 640x360 Current / Optimal Res 640x360@30 / 640x360@30 (right click on the player window and select "Stats for nerds") so you're getting a 640x360 @ 30fps content. You need to force the resolution. BTW, that stream is running at a maximum of 30fps, so I don't see where you're getting those 60fps stats. My 8 core mac 2013 pro plays them just fine, all with software decoder (this machine for some reasons doesnt have the HW decoder active, even when the hardware supports it) The other thing you're likely not considering, is that if you disable the HW decoder, you will no longer receive h264 in YouTube but VP9. To force H264 at all time, you need in about:config need to set media.webm.enabled to false So really, you are comparing H264 HW accelerated vs VP9 software.
(In reply to Mark from comment #132) > Oops, shows I don't use YouTube much. It claims to be running at 1080p & 60 > fps by default. I tried some 1440p videos but couldn't get any of them to > play at >40 fps even in Safari. I can't find any "real" 4k stuff. So no idea > what's going on. Anyway I looked at a few videos and forced them all to > 1080p & 60 fps and got much the same results. I tried changing the zoom YouTube no longer serves content > 1440p @ 30fps with h264, only with VP9 codec which safari doesn't support. This one https://www.youtube.com/watch?v=R3AKlscrjmQ has 4K and 60fps content (it's a beauty really). You will be limited to 1080p/60fps H264 however with h264. So Firefox (if you force enabled webm with media.mediasource.webm.enabled set to true) and Chrome will give you 2160p@60fps , otherwise you'll get 1080p/60fps
See Also: → 1428842
Depends on: 1430884
I can confirm that running Firefox in "Low Resolution Mode" gets rid of any performance issues. Once I started the app like that, it was smooth as it should be. What happens with normal mode: - Slow loading of pages - JS seems to be executing slower (AJAX requests seem to take noticeably longer) - CPU usage jumps With Low Resolution mode, all of the above are back to normal. Of course the browser now looks blurry, but it seems to have fixed it all. System: MacBook Pro (Retina, 13-inch, Early 2015) OS: OSX High Sierra 10.13.3 (17D47) Firefox: 58 stable release Same behavior on latest Nightly
I expect that you'll get full performance at high scaled resolution without resorting to Low Resolution when bug 1429522 is fixed. But I expect even then battery life will be poor at high scaled resolution unless/until bug 1423324 is fixed.
Flags: needinfo?(dglastonbury)
Marking 60 as affected. It is too late for a fix for 59 though.
status-firefox59: affected → wontfix
status-firefox60: ? → affected
tracking-firefox60: --- → +
Hello, I have MacOS sierra 10.12.6 with FF 59.01 and having now set "Low Resolution" mode improved drastically Firefox speed and over-heating fan!
I am currently ramping up a survey to run on our MacOS audiences for some quantitative analysis. We will run it on pre-57 users as well as current release users on Windows for a baseline of self-reported fan usage and battery drain. We will be able to connect with telemetry for those users who self-report high drain or high fan usage. Are there other factors that will be valuable (or is research into this bug progressed far enough that we don't need this additional research).
The window transparency seems to be a big enough problem that it will be hard to see other problems. (We'll hopefully have a pref to control this soon). The window has been transparent for a long time. The other big thing that changed with 57 was 60fps throbbers. Setting browser.tabs.hideThrobber=true will allow users to hide the throbbers and this seems to give a big improvement for some users. Having 60fps throbbers makes the window transparency problem more acute because we're consuming twice as much bandwidth as we need to at 60fps instead of the old 15fps. This can starve other parts of the browser.
Re Comment 140 I am just an end user but I fiddled with this bug a lot and I would say the same as Jeff, I would wait until Jeff & team have done their transparency & Core Animation fix(es?). I think the fix(es) will dramatically improve the Mac heat/fan/battery life/slowdown situation. If there is any doubt perhaps you could make the fixes opt-in somehow and do a survey/get feedback from opting-in users? (I don't know how you would do that).
@Jeff are these new prefs live in Nightly? I saw Autoland stuff a few days ago:- 7bc1183fb32e: Bug 1448133 - Add a Nightly-only preference to set the tab throbber to animate at 30fps. MozReview-Commit-ID: 77Bo8B8F8jE 03970f62dcf1: Bug 1447153 - Add a Nightly-only preference to hide the tab throbbers for performance diagnostics. MozReview-Commit-ID: LwAiKFR9Pew but I can't find browser.tabs.30FpsThrobber or browser.tabs.hideThrobber in Mac Nightly 2018-03-27 Am I missing something [or am I being dumb ;) ]?
(In reply to Mark from comment #143) > > Am I missing something [or am I being dumb ;) ]? Not being dumb at all - the prefs don't exist by default, so you need to add them by right-clicking in about:config, and choosing to create a new boolean pref. Note that these prefs are on Nightly-only, and are purely for testing purposes.
Thanks. I look forward to fiddling with that, let's see what I can break ;)
Depends on: 1449271
Is there anything an end user can do here to help out in testing. I really want to switch back to FX but can't because of this. Disabling opacity and throbbers did help out a bit, but for me the laptop still overheated and the fans started to blaze, so it didn't eliminate the issue.
Gorjan, can you post a profile with opacity and throbbers disabled?
Here we go: https://perfht.ml/2GSvYvG This included scrolling trough a FB feed and playing a YouTube video in a second tab. After just 30 seconds I could feel the laptop overheating.
Your content processes seem to be pretty busy doing stuff for your DuckDuckGo Privacy Essentials add-on. Does disabling that help?
Flags: needinfo?(computergeny)
Indeed seems to help when I killed all addons. Where in the profile can I see what addon is causing stress on the content process?
Flags: needinfo?(computergeny)
(In reply to Gorjan Jovanovski from comment #150) > Indeed seems to help when I killed all addons. Where in the profile can I > see what addon is causing stress on the content process? We don't do a great job surfacing that just yet, but I filter on the word "extension" by habit as a first pass when doing analysis.
FYI I am unable to get https://perf-html.io working in FF60. The addon installed successfully but it does not appear in my toolbar.
(In reply to lochie from comment #152) > FYI I am unable to get https://perf-html.io working in FF60. The addon > installed successfully but it does not appear in my toolbar. Any errors in the browser console? https://developer.mozilla.org/docs/Tools/Browser_Console If you see errors messages or have steps to reproduce, please file a separate bug for this and needinfo me.
Here's my oerf profile from reloading this tab and then opening facebook.com (which is the laggiest on MacOS FF for me, but loads fast on Ubuntu machine): https://perfht.ml/2s3duyT Is this helpful enough? Would there be other suggestions? Even typing this text is laggy under Retina MacBook on FF.
I'd love to use Firefox, but as soon as I use any Single Page App, my fans spin up and Firefox kills my batter. Perf profile here: https://perfht.ml/2Lup8Lj I've also tried the Beta channel with these two options, but they did not fix the issue: - browser.tabs.20FpsThrobber - browser.tabs.30FpsThrobber Thanks for any help in resolving this issue! It's unfortunately a deal-breaker for me.
(In reply to brian from comment #155) > I'd love to use Firefox, but as soon as I use any Single Page App, my fans > spin up and Firefox kills my batter. Perf profile here: > https://perfht.ml/2Lup8Lj The CPU in this profile is spent in gitter.im and mail.google.com. I don't see any obvious Firefox bug in there.
(In reply to Florian Quèze [:florian] from comment #156) > (In reply to brian from comment #155) > > I'd love to use Firefox, but as soon as I use any Single Page App, my fans > > spin up and Firefox kills my batter. Perf profile here: > > https://perfht.ml/2Lup8Lj > > The CPU in this profile is spent in gitter.im and mail.google.com. I don't > see any obvious Firefox bug in there. Is there any way I can provide more helpful information? When I open these sites in Safari or Chrome, I do not experience battery drain. With Firefox, my fans immediately spin up and my battery starts draining very quickly. That's why I chose to profile those two sites.
@brian Does "Open in Low Resolution" mode https://support.apple.com/en-gb/ht202471 help with the fans and battery?
(In reply to Mark from comment #158) > @brian > > Does "Open in Low Resolution" mode > https://support.apple.com/en-gb/ht202471 help with the fans and battery? No change on my end Mark, CPU temperature jumped 20 degrees in < 1min when I opened FF and went to Twitter.
Don't worry too much about CPU temp, it can be a red herring, the aim of Low Resolution Mode is to see if your graphics processor (GPU) is working very hard. There is a bug in Firefox which causes this. Instead check fans and battery life... use Low Resolution Mode for a while, see if it helps battery life & fans.
(In reply to Mark from comment #160) > Don't worry too much about CPU temp, it can be a red herring, the aim of Low > Resolution Mode is to see if your graphics processor (GPU) is working very > hard. There is a bug in Firefox which causes this. Instead check fans and > battery life... use Low Resolution Mode for a while, see if it helps battery > life & fans. I wouldn't call CPU temp a red herring. My computer is sitting on my lap - burning - my battery is draining faster than usual, and the fans are going nuts. Firefox is doing something fundamentally wrong here, and surprising that the issue hasn't been tracked down yet. My CPU isn't pinned, it's just that Firefox is not power conscious at all on my computer. For what it's worth, Firefox's CPU usage is higher than Chrome on my computer. I wouldn't call it considerable though. So where is the battery consumption coming from? I'm on a late 2013 rMBP with an i7 Haswell chip. I can't imagine CPU hardware has changed significantly in 4 years.
> So where is the battery consumption coming from? The GPU. This sounds exactly like bug 1422090. Firefox works the GPU very hard. The GPU can easily generate more heat and hit the battery harder than the CPU. Try Low Resolution Mode for a while. If you want to get scientific, download Intel Power Gadget and take a look at your Intel package (CPU+GPU+memory controller) power consumption in normal vs Low Resolution mode.
(In reply to Mark from comment #158) > @brian > > Does "Open in Low Resolution" mode > https://support.apple.com/en-gb/ht202471 help with the fans and battery? Hi Mark, thanks for your suggestion. I've been using Firefox for about 30 mins in Low Resolution mode, and my fans have remained quiet and my battery life is certainly improved!
Good. The proposed fix is in bug 1429522, you can follow progress there. Not much to see at the moment but I believe stuff is going on in the background - but the fix is not simple.
If it could be useful, since 3/4 days I maintain opened about:memory and I click about every 10 minutes the "Minimize memory usage" button; I haven't high fans usage anymore.
Is there any workaround for this? Some Nightly/DevEdition/Beta + some about:config trickery? I do support and a lot of people on Twitter are affected by this.
Yes, but they are quite hacky, see below. It would be nice to hear an update from the Mozilla guys on this issue, it's been 6 months since the fix was proposed in bug 1429522. Hacky fixes:- Use Firefox Nightly set gfx.compositor.glcontext.opaque TRUE set browser.tabs.20FpsThrobber TRUE restart Firefox (I think these only work on Nightly) If necessary also lower your Retina screen resolution one notch or two notches in System Preferences > Displays. Have a play, you should get an idea of where the compromise is between screen resolution and heat/fans/battery consumption. You might find some problems with the Firefox sidebar, it sometimes appears black on black. And you might see some other artifacts. But it works OK for me.
Thank you!
Anyone still working on this? It's a huge blocker on Mac and is visibly slower on almost all websites compared to Chrome.
(In reply to Gorjan Jovanovski from comment #169) > Anyone still working on this? It's a huge blocker on Mac and is visibly > slower on almost all websites compared to Chrome. Several people have reported that bug 1265824 helped solve this, perhaps you could try using nightly for a bit and see if that helps?
(In reply to bgstandaert from comment #170) > (In reply to Gorjan Jovanovski from comment #169) > > Anyone still working on this? It's a huge blocker on Mac and is visibly > > slower on almost all websites compared to Chrome. > > Several people have reported that bug 1265824 helped solve this, perhaps you > could try using nightly for a bit and see if that helps? Oh wow, I think that fix worked for me! My fans no longer spin up when using Firefox, draining my battery at an alarming rate. I still think Firefox could have a bit better battery life even with this patch, but this is a huge improvement, and has let me switch back to Firefox as my main browser.
I would be surprised if the fix for bug 1265824 had any major impact on Firefox power consumption on Mac. Because IIUC the main source of high power consumption is not actually Firefox itself, it's the MacOS window compositor. The window compositor uses a lot of power at high scaled resolutions and so it is very important for apps to minimise the number of pixels / second they send to the MacOS compositor to minimise the amount of work it has to do and the amount of power it uses. Apps can do this by using the Core Animation API. Firefox doesn't use Core Animation at the moment so it sends too many pixels / second to the compositor which causes high power consumption, particularly on the GPU. Also Firefox sends *transparent* pixels which makes the MacOS compositor work even harder. Bug 1265824 doesn't affect the number of pixels / second sent to the MacOS window compositor, or the transparency of those pixels, so I doubt it has a major impact on power consumption. Bug 1265824 does affect the amount of memory copying that takes place between CPU and GPU so perhaps that helps with power consumption a little? And it certainly helps with frames / second on some animations. I still have serious power consumption problems at high scaled resolutions with bug 1265824 fixed. But I can't explain what other people are seeing (or hearing) with their fans.
(In reply to Mark from comment #172) > I would be surprised if the fix for bug 1265824 had any major impact on > Firefox power consumption on Mac. Because IIUC the main source of high power > consumption is not actually Firefox itself, it's the MacOS window > compositor. The window compositor uses a lot of power at high scaled > resolutions and so it is very important for apps to minimise the number of > pixels / second they send to the MacOS compositor to minimise the amount of > work it has to do and the amount of power it uses. Apps can do this by using > the Core Animation API. Firefox doesn't use Core Animation at the moment so > it sends too many pixels / second to the compositor which causes high power > consumption, particularly on the GPU. Also Firefox sends *transparent* > pixels which makes the MacOS compositor work even harder. > > Bug 1265824 doesn't affect the number of pixels / second sent to the MacOS > window compositor, or the transparency of those pixels, so I doubt it has a > major impact on power consumption. Bug 1265824 does affect the amount of > memory copying that takes place between CPU and GPU so perhaps that helps > with power consumption a little? And it certainly helps with frames / second > on some animations. > > I still have serious power consumption problems at high scaled resolutions > with bug 1265824 fixed. But I can't explain what other people are seeing (or > hearing) with their fans. Fair point -- I don't know the details and I'm not sure what other changes have been made to Nightly, but thankfully it's far better on power consumption / fan usage than past builds.
> Firefox doesn't use Core Animation at the moment so > it sends too many pixels / second to the compositor which causes high power > consumption, particularly on the GPU. Using Firefox with external display causes the device to quickly climb to >60degrees Celsius forcing fans to spin (which doesn't help much and the device is still quite hot most likely due to excessive GPU usage). Would be nice to have some rough idea if/when this issue could be addressed.
Can confirm that the latest Nightly builds have made no palpable difference in performance or battery consumption. 1680x1050 HiDpi (MBP 13' 2015) renders it basically unusable. 1680x1050 resolution (Non HiDpi) kind of fixes the issue, but of course resorting to the measure is not practical. Would be great if this issue got a bit more attention, surely anybody using retina macbook and firefox doesn't have it any better? FWIW here's my perf https://perfht.ml/2ocRKiK
FF62. MBP-15 mid-2015. macOS 10.13.6 I was originally insulated from the problem because I used FF with an external monitor that did not have super-high DPI. But with the laptop's screen, I was getting energy usage so high that the battery was draining *while plugged in!* Setting FF to Low Resolution (https://support.apple.com/en-gb/HT202471) and restarting the application made an enormous positive impact. The less-crisp UI is mildly annoying, but still better than a furnace on my lap.
I am running Nightly 64.0a1 (2018-09-13) (64-bit) The problems seem to be gone for me. Smooth operation on scaled resolution, no overheating, no significant battery drain. Seems can others confirm?
Unfortunately, problems are still there for me on 64.01 (2018-09-14) (64-bit)
The problem seems to have been resolved for me. At least so far as that Firefox Nightly is not present on the list of apps that use significant battery, and haven't been since I upgraded to latest version. Before the upgrade, it was constantly present on the list. Version: 64.0a1 (2018-09-15) (64-bit)
(In reply to chrisbuchholz from comment #180) > The problem seems to have been resolved for me. At least so far as that > Firefox Nightly is not present on the list of apps that use significant > battery, and haven't been since I upgraded to latest version. Before the > upgrade, it was constantly present on the list. > > Version: 64.0a1 (2018-09-15) (64-bit) Seems to have been a fluke... It started again, and now just stays on the list.
I've switched from Chrome to Firefox Quantum since its launch on my Late 2013, Retina Display 13'' Macbook Pro. I've been suffering because of this issue since then but I cannot go back to Chrome any more. :) (Great work, thanks!) I realized that when I plug the computer to the external display (Dell U2715H), Firefox works fine. The CPU usage and the overall performance of the browser seems better. However when I switch back to Mac's own display, the CPU spikes and the overall performance degrades. After a while, I switched to Firefox Developer Edition and it gradually got better over time with every release. If I scale down the display, the performance is as expected. But when I'm using Mac's own display with its max resolution (2560 x 1600) the performance is really bad. GMail usage, tab switching, scrolling etc is kind of laggy. Sometimes it takes a while to render the page if you scroll too fast. :) I just wanted to check out whether this issue has been solved and learnt about the "low resolution mode" per app. Gave it a try and the performance is much much better. I can understand the amount of work it may require to support Core Animation API, thanks for all the efforts you put into Firefox, really appreciated!
Whiteboard: [gfx-noted] → [gfx-noted][qf]
I take my comment back, the issues are still here on my machine too :(
Hi, Problem is still there. Version 62.0.2 (64-bit). It's easy to heat up my mac fan just by browsing actively (7 or 8 tabs, gmail, netflix, nothing special..). Is there any profiling we can submit to help? Again, running the app in low resolution mode fix the issue for me, but the web is super ugly.
Same issue. Retina late 2013 13" MBP here. Latest Firefox. Firefox consuming 100%+ CPU and pages take forever to load. As much as I hate what Google is doing with Chrome right now, I can't switch to Firefox when it's unusable on this laptop.
dbolter: this has been around for a while and still seems to be a problem. Can you find someone to investigate?
Flags: needinfo?(dbolter)
Good question. Matt do you know who could look at this? Maybe looking at bug 1421638 is a next step?
Flags: needinfo?(dbolter) → needinfo?(matt.woodrow)
I'm not sure if this has been brought up, and I didn't know until I bought a new rMPB recently, but Apple has changed the default resolution from exactly 2x to some non integer scaled resolution that provides more space but taxes the GPU more. So people with stock macOS installs will have this problem.
It seems to me that the title of this bug is misleading. While it is true that when setting Firefox to low resolution mode this does not make the problems go away it only lessens them. At least that is the result on my end. And this seems also implicit in some of the answers to resolution change I have seen here. But CPU is still way higher than in other browsers, the battery taxed too much and fans still kick in far too quickly. As a result, this still decreases the life-span of the MacBook. Couldn't the better performance of Firefox be put as a change in degree due to the lower resolution than a change in kind? I just wanted to make sure that the problem is not put in the wrong camp. But surely someone at Mozilla has a MacBook and can reproduce the bug, or?
The issue also exist on non retina macbook pro. On mine mid-2012 with clean install of Firefox (even Nightly) temp grow up quickly when it is launched and when I load some websites :( Battery drain is so important to use Firefox everyday. Really hope a fix soon.
Can the community do anything to help you guys out in testing? It's obvious that a lot of people can recreate it, maybe we can mass test multiple fixes you guys think might help?
I think the solution to the main power problem is clear. It's bug 1429522 and its five sub-bugs:- bug 1491422, bug 1491455, bug 1491448, bug 1491451 and bug 1491456. IIUC the problem is that these are not simple bugs to fix. They need substantial re-engineering of the way the two compositors (CPU based and WebRender) operate. Mozilla has taken the first steps (e.g. there is a patch for bug 1491422) but I think there is a long way to go. So I guess we are all going to have to be patient. Also, it's possible that there are other power issues on Macs. But paraphrasing a Mozilla guy on here, bug 1429522 causes such high power consumption that other issues might not be visible until it's fixed.
What Mark said in comment 192 is correct. I'm making this bug depend on bug 1429522 which is the tracker for the first piece we need in order to make some progress here.
Depends on: 1429522
Flags: needinfo?(mstange)
Flags: needinfo?(matt.woodrow)
Whiteboard: [gfx-noted][qf] → [gfx-noted]
https://www.tagesschau.de/multimedia/audio/audio-59273.html(In reply to Markus Stange [:mstange] from comment #193) > What Mark said in comment 192 is correct. I'm making this bug depend on bug > 1429522 which is the tracker for the first piece we need in order to make > some progress here. I must confess that I do not understand fully what bug 1429522 is about but shouldn't mere audio playback be independent of it? If so, then bug 1482642 cannot depend on it and hence it is no duplicate of the current bug after all.
(In reply to xracoonx from comment #194) > I must confess that I do not understand fully what bug 1429522 is about but > shouldn't mere audio playback be independent of it? If so, then bug 1482642 > cannot depend on it and hence it is no duplicate of the current bug after > all. I looked at your link. I think the problem is that there are animations while music is playing. The animations seem to run at 60 fps so Firefox is forced to paint the whole window at 60 fps which uses a lot of GPU power. So I think bug 1429522 and bug 1491456 are affecting you. Try grabbing the corner of your Firefox window and making the window much much smaller e.g. 10% of the whole screen area. Then play the music again. For me this reduces the power consumption while playing music. Or, open Firefox in Low Resolution mode. Firefox window 100% of screen size -> total machine power ~40 watts & very loud fan & ~1.5 hour battery life Firefox window ~10% of screen size -> total machine power ~14 watts & very quiet fan & ~4 hour battery life MacBookPro11,1 @ 1440x900; 75% brightness; Firefox Nightly in stock configuration (gfx.compositor.glcontext.opaque FALSE; gfx.webrender.all FALSE) I think this is a good example of the bug. Even the very small animation (the bar graph while music is playing) causes enormous GPU power consumption. That's what the bug is all about. Even the Firefox tab throbber can cause enormous power consumption/heat/fans and can slow the whole machine down.
I’ve been following this from a distance because I get email notifications for this and a bunch of related bugs because I reported this issue last year. I hope no one takes offense to this and I’m only saying it because I have watched this go on for a year now with seemingly no progress. I just have a question / suggestion. What I’m seeing in these discussions is a lot of tweaking attempts and maybe a patch that minorly addresses part of the issue - all really to no end. I’ve said on this all along - the approach Mozilla took with the Mac on the Quantum rewrite was completely wrong headed. Apple has a a very advanced accelerated graphics subsystem which from what I can gather Firefox never used. It wasn’t a big deal before, but with quantum they decided to add A bunch of animations and also move a bunch of tasks that were formerly done by the CPU to the GPU (which sounded great on paper - but I’m not sure is working out in practice). All of this on a non OS accelerated graphics subsystem on Thr Mac, which meant that anyone with a Mac that uses scaled resolution (which in the past was advanced users and now is all new laptops) their laptop starts to sound like a jet on an aircraft carrier about to take off. Laptops noticed it more - but my iMac definitely used more resources when running Firefox than other browsers, it just had more headroom to play with. Here’s my question / suggestion. The answer to this is to use CoreAnimation for all graphics rendering. Completely offload all graphics rendering to the OS. No other Mac app I’ve ever used (including Chrome & Safari) has the problem that Firefox 57+ has. That’s because graphics rendering on the Mac is a very very solved problem. All other apps use CoreAnimation. So I guess my question is - what is the overall plan to move Firefox to CoreAnimation? I get notifications on like 5 different bugs and i see small efforts to maybe move a bit of the rendering to CoreAnimation, but this really doesn’t seem to be going anywhere. Anything else that’s done (disabling throbbers / using low resolution mode) is going to futile and is a waste of time. I actually no longer have a dog in this hunt. I don’t use a Mac anymore, I’ve switched to iPad full time. Ironically Firefox on iOS is amazing - because it uses all the built in apis. But for the good of the overall web I’d like to see this get fully fixed on the Mac. I’m astounded not only that Firefox 57 shipped this way, but that a year later it’s still a major issue. I honestly don’t understand how this is possible. Doesn’t anyone at Mozilla have a Mac laptop that they use in scaled mode? I have no ill intent with this post, it’s just got to the point where I’ve watched this long enough and I felt like I needed to add my thoughts.
Re comment 192 the equivalent bug for WebRender is (I think) https://github.com/servo/webrender/issues/3115. The comments give some useful background.
Re comment 196 @Charlie, just a few comments on your post. I am no expert on browsers but I have followed this bug since its early days and have done a lot of the power measurements which led to bug 1429522 etc. My (poor) understanding is this "use Core Animation for all graphics rendering" doesn't really mean much. Core Animation is fairly broad and flexible. Firefox could send via Core Animation the whole frame buffer object (circa 6 Mpixels @ 60 fps) like the current Firefox compositor(s). Which won't improve power consumption - much - see bug 1491422 and my bitching about its power. Or it could a simplified set of layers and do final compositing in MacOS as described in https://github.com/servo/webrender/issues/3115#issuecomment-424125485. But I think that has power disadvantages too due to "layer heuristics" and managing the number of layers. Or it could output Core Animation layers as described in https://bugzilla.mozilla.org/show_bug.cgi?id=1491456#c0 which would be horrendously complicated involving re-engineering the Firefox compositor. Core Animation is not a universal fix for GPU power problems. A specific example would be bug 1491422. This is a patch to switch Firefox to using the Core Animation path. It didn't reduce power consumption very much (and I started bitching). Safari - which uses Core Animation - has horrible GPU power consumption when scrolling some sites - bugzilla is one - which I think might be down to too many layers having to be composited in MacOS. This might be the "layer heuristics" mentioned in some of these comments. Remember we've got two problems here - too many pixels being composited by MacOS; and those pixels being blurred/transparent (aka vibrant). The aim I think is to get away from Firefox requiring the MacOS compositor to do vibrancy calculations and Retina interpolation on circa 6 Mpixels @ 60 fps because that uses huge amounts of GPU power. One step would be to divide the window into vibrant regions (the URL bar; the sidebar) and non vibrant regions (eg the web content). Then tell Core Animation about the different regions separately. That should fix the vibrancy power consumption because the (vibrant, high power) sidebar and URL bar remain static and so don't need to be re-composited by MacOS when the (opaque, low power) web content updates during eg scrolling. But that's not enough, power consumption is still too high in situations where only small regions are animating like throbbers. So the plan I think is to divide (or further subdivide?) the window region(s) into little tiles and only tell MacOS about the tiles which change from frame to frame. Of course there will be situations where the whole screen is moving (e.g. scrolling) where it can't be avoided (if you fool with Safari and Chrome you'll see that all of the browsers are awful in this regard). But most of the time only a small part of the screen is animating. If in these cases Firefox can tell the MacOS compositor to update a few tiles, say 10% of the screen's pixels, the GPU power should drop to the point where it's well below the CPU + screen + etc and becomes negligible. From my very limited understanding the proposed approach, particularly as described in https://github.com/servo/webrender/issues/3115 seems quite pragmatic. I think it will produce the necessary power saving without having to re-engineer the whole of Firefox's compositor. In some situations Firefox might use less power than Chrome/Safari. In others it'll use more. But I suspect in real world use it'll be broadly the same. As for how long it's all taking, who knows? It's clearly terribly complicated, and the Mozilla graphics guys have been working very **** WebRender, etc, etc.
Actually, the tl;dr version of that waffle is Core Animation won't fix the power problem. Breaking the window into lots of teeny tiny tiles and only telling MacOS about the tiles which change from frame to frame WILL fix the power problem. Firefox needs to be re-engineered to generate the tiles, which is relatively difficult. And then Core Animation will allow Firefox to send only the changing tiles to MacOS, which is (I think) relatively easy.

the performance impact of this issue is still one of the most common sort of feedback/complaints we see from macos users on various support channels.

status-firefox64: fix-optional → wontfix
status-firefox65: fix-optional → wontfix
status-firefox66: --- → wontfix
status-firefox67: --- → affected
status-firefox68: --- → affected

(In reply to MB from comment #202)

As a Mac user who is currently evaluating browsers outside of Safari, I was surprised to see how wonderful Firefox has become in its current iteration but also, unfortunately, how much CPU it uses. This makes the laptop very warm and cuts battery life in half.

Simply, Firefox is unusable on a Mac laptop. That this issue has been around for 2 years is even more surprising to me. If not for this, I would switch to Firefox full time on all my devices.

It's quite telling that my wife, who has absolutely no techie blood in her, turned to me after I put FF on her MacBook and said "why is my laptop so hot and noisy now?"

you're comparing apple and oranges. The only browsers on mac with good battery life and CPU usage is Safari. Primary reason is that Safari doesn't support VP9 video codec.
If your browser tests were done on YouTube then Safari will indeed give you great battery life, because all video decoding is hardware accelerated. But you're also limited to 1080p as it uses H264 only

Firefox on the other hand would use VP9, can do 4K and more with YouTube, at the expense of CPU usage.

Don't want to use VP9, then set media.webm.enabled to false.
It will reduce CPU usage greatly. But the video quality will suffer.

Having said that, even when Firefox uses only H264, Safari will provide better battery usage..

(In reply to Jean-Yves Avenard [:jya] from comment #203)

you're comparing apple and oranges. The only browsers on mac with good battery life and CPU usage is Safari. Primary reason is that Safari doesn't support VP9 video codec.

But the problem is not restricted to video.

Work is still happening in bug 1491442.

(In reply to Jean-Yves Avenard [:jya] from comment #203)

you're comparing apple and oranges. The only browsers on mac with good battery life and CPU usage is Safari. Primary reason is that Safari doesn't support VP9 video codec.

(In reply to xracoonx from comment #204)

(In reply to Jean-Yves Avenard [:jya] from comment #203)

you're comparing apple and oranges. The only browsers on mac with good battery life and CPU usage is Safari. Primary reason is that Safari doesn't support VP9 video codec.

But the problem is not restricted to video.

A small gif and audio makes my MacBook Pro 2015 fans spin. For example on https://www.tagesschau.de/multimedia/audio/audio-75005.html.

(In reply to xracoonx from comment #210)

A small gif and audio makes my MacBook Pro 2015 fans spin. For example on https://www.tagesschau.de/multimedia/audio/audio-75005.html.

Just listened to the full 90 secs with no fan spinning;
MacBook Pro (Retina, 15-inch, Mid 2015) | 10.14.6 | FF Nightly 70.0a1 (2019-08-02)

(In reply to Albert Scheiner [:alberts] from comment #211)

(In reply to xracoonx from comment #210)

A small gif and audio makes my MacBook Pro 2015 fans spin. For example on https://www.tagesschau.de/multimedia/audio/audio-75005.html.

Just listened to the full 90 secs with no fan spinning;
MacBook Pro (Retina, 15-inch, Mid 2015) | 10.14.6 | FF Nightly 70.0a1 (2019-08-02)

Fan going full speed after 55 sec..

MacBook Pro (Retina, 13-inch, Late 2013)
FF Nightly 70.0a1 (2019-07-30) (64-bit)

(In reply to xracoonx from comment #210)

A small gif and audio makes my MacBook Pro 2015 fans spin. For example on https://www.tagesschau.de/multimedia/audio/audio-75005.html.

Thank you for this excellent test case! While I can't get it to make the fans spin on my machine (MacBook Pro (Retina, 16-inch, Early 2013)), I do see significant power usage in Intel Power Gadget on this page. It's a page where only a small part of the screen is changing, so I'm expecting my planned work (especially bug 1491456 and bug 1491451) to improve this a lot. That work won't help with cases where most of the screen is changing, such as scrolling and full screen video, but it should help with small animations such as this one.

Depends on: 1571551

I just confirmed that opening https://www.reddit.com/r/StoppedWorking/comments/du45he/deskexe_was_not_found spikes my CPU to 200% (macOS Catalina 10.15.1 on a 13" MBPr 2015).

Now that multitouch zoom is finally supported (yay!) (https://www.reddit.com/r/firefox/comments/bcebze/_/erimc1y), this issue is literally the only thing keeping me on Chrome, so fingers crossed that it gets resolved soon.

There doesn't seem to be any update on this bug since a year now. Together with this list https://bugzilla.mozilla.org/buglist.cgi?quicksearch=keywords%3Apower%20os%3AmacOS it seems that there is not a lot of activity in general on fixing the power consumption issues under macos since bug 1491456 and bug 1491451 , probably due to resources, priorities or other issues

I'd appreciate therefore if you could communicate your plans on this topic, do you plan to give some prioritization or rough target dates ?

Just for the record, my battery with firefox lasts ~4h, without firefox 7+h (eg. edge, safari)
thanks

(In reply to George Billios from comment #216)

Just for the record, my battery with firefox lasts ~4h, without firefox 7+h (eg. edge, safari)

Do you have some example pages where that happens? Also what's your hardware configuration, and display settings. Are you using a scaled resolution? Right now I cannot reproduce high CPU usages, but with a testcase we could figure out what's going on. Thanks!

Flags: needinfo?(gbillios+mozilla)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #217)

(In reply to George Billios from comment #216)

Just for the record, my battery with firefox lasts ~4h, without firefox 7+h (eg. edge, safari)

Do you have some example pages where that happens? Also what's your hardware configuration, and display settings. Are you using a scaled resolution? Right now I cannot reproduce high CPU usages, but with a testcase we could figure out what's going on. Thanks!

Macbook pro 2018 with scaled resolution

Just having the following pages open, video not playing or buffering, results in a ~6-9% cpu usage, Energy impact on 6-12 and this is only an example

https://www.neowin.net/
https://www.youtube.com/watch?v=lacmtG0V-uk
https://bugzilla.mozilla.org/show_bug.cgi?id=1404042

same pages on Edge (chromium), cpu 0,5 with some spikes to 5%
same pages on Safari <1%

as soon as firefox is in focus, doing nothing the above utilization happens. Typing this comment, shoot cpu utilization to 15%+

Flags: needinfo?(gbillios+mozilla)

(In reply to George Billios from comment #218)

Macbook pro 2018 with scaled resolution

Which exact resolution have you choosen?

Just having the following pages open, video not playing or buffering, results in a ~6-9% cpu usage, Energy impact on 6-12 and this is only an example

Would you mind to record a profile while these pages are open via https://profiler.firefox.com? The CPU load might still be too low to see something in such a profile but it would be good to have one.

as soon as firefox is in focus, doing nothing the above utilization happens. Typing this comment, shoot cpu utilization to 15%+

The textarea field has a couple of event handlers (keydown, input) registered and as such executes Javascript code. That means that the CPU utilization will indeed be higher. Other browsers should actually show the same, and specifically that behavior isn't related to this bug.

as soon as firefox is in focus, doing nothing the above utilization happens. Typing this comment, shoot cpu utilization to 15%+

The textarea field has a couple of event handlers (keydown, input) registered and as such executes Javascript code. >That means that the CPU utilization will indeed be higher. Other browsers should actually show the same, and specifically that behavior isn't related to this bug.

Actually with safari using the textarea the utilization only goes to ~4-5% max, firefox is 3times that

Which exact resolution have you choosen?

1680x1050

Would you mind to record a profile while these pages are open via https://profiler.firefox.com? The CPU load might still be too low to see something in such a profile but it would be good to have one.

here you go
https://share.firefox.dev/3l6pHwn

(In reply to George Billios from comment #220)

here you go
https://share.firefox.dev/3l6pHwn

There's something weird going on in the "DOM Worker" thread. Do you see this on a fresh restart of Firefox?

Flags: needinfo?(gbillios+mozilla)

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

(In reply to George Billios from comment #220)

here you go
https://share.firefox.dev/3l6pHwn

There's something weird going on in the "DOM Worker" thread. Do you see this on a fresh restart of Firefox?

I wonder if we should get this better filed / discussed on a new bug. It would also be good to have other processes included in the profile. So maybe only running Firefox with these three tabs open, and uploading / publishing the full profile would be good.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #222)

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

(In reply to George Billios from comment #220)

here you go
https://share.firefox.dev/3l6pHwn

There's something weird going on in the "DOM Worker" thread.

I explained this in bug 1633318 comment 24.

It would also be good to have other processes included in the profile. So maybe only running Firefox with these three tabs open, and uploading / publishing the full profile would be good.

It seems the profile in comment 220 was captured with the "Web Developer" preset; using the "Firefox Front-End" preset would show us more information.

Another way to get some information about which threads are using CPU time would be to look at about:processes after setting the toolkit.aboutProcesses.showThreads preference to true in about:config. (Click the "CPU" column header to sort by CPU use and see at the top the threads that use the most CPU).

hi all,

first of all here is the profile with Firefox Front-end profiling set
https://share.firefox.dev/2VecBmg
I'm afraid I can't share the full profile in this machine

after the last time I took my time and disabled a few extensions that seem to have reduced the "idle" cpu usage with these pages open down to 1-5% from 6-9%, still high compared to safari for example

I also attach the processes_with_threads.png while doing nothing

regardless of the changes - even on safe mode or fresh profile - the extra cpu utilization remains. Of course when a youtube video plays, forced to h264, the utilization is much much higher than with safari or edge/chrome

at the end of the day we/I just need to understand if there are possibilities for further optimization in general, thanks

Flags: needinfo?(gbillios+mozilla)

Hi Jim,

I'm Need Info'ing you since you are the triage owner of Core: Graphics and because the reporter is no longer active.
I haven't been able to reproduce a poor battery usage on a Macbook while using the latest Firefox versions (Release, Beta and Nightly).

Since this bug has many comments and issue seems to be P2, I'd appreciate your input. Is this still being investigated/worked on?

Thanks,
Virginia

Flags: needinfo?(jmathies)

Brad, mind trying to triage this mess of bugs?

Flags: needinfo?(jmathies) → needinfo?(bwerth)

Yes, I'll investigate.

Assignee: nobody → bwerth
Flags: needinfo?(bwerth)
Performance Impact: --- → P3
Keywords: meta, perf:resource-use
Summary: Poor battery life on OSX with scaled resolution → [meta] Poor battery life on OSX with scaled resolution

Meta bugs probably don't need owners. I'll look at the dependencies and make sure they have assignees or at least priority.

Assignee: bwerth → nobody

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Severity: -- → S3

George, does this still reproduce for you?

Flags: needinfo?(gbillios+mozilla)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(gbillios+mozilla) → needinfo?(bhood)

All blockers resolved, this can be closed.

Status: NEW → RESOLVED
Closed: 4 months ago
Flags: needinfo?(bhood)
Resolution: --- → FIXED

I agree, we're in a much better state today than when this bug was opened. The initial CoreAnimation work helped a lot, and then further improvements were made in WebRender: We now scroll by moving CALayers rather than by repainting their contents (in the common cases at least), and we use AVSampleBufferDisplayLayer for video playback.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: