Improve compositing power usage on macOS by using CoreAnimation
Categories
(Core :: Widget: Cocoa, defect, P1)
Tracking
()
People
(Reporter: jrmuizel, Assigned: mstange)
References
Details
(Keywords: perf:resource-use, Whiteboard: [wr-planning])
Attachments
(2 obsolete files)
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 2•7 years ago
|
||
Comment 4•7 years ago
|
||
Comment 5•7 years ago
|
||
Assignee | ||
Comment 7•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Assignee | ||
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Assignee | ||
Comment 12•7 years ago
|
||
Comment 13•7 years ago
|
||
Comment 14•7 years ago
|
||
Updated•7 years ago
|
Comment 15•7 years ago
|
||
Assignee | ||
Comment 16•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 17•6 years ago
|
||
Any updates on this?
Assignee | ||
Comment 18•6 years ago
|
||
Work has begun.
Comment 19•6 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #18)
Work has begun.
Excellent! That's great news. Thank you.
Comment 20•6 years ago
|
||
Any chance of getting this bumped to P1? Patrick in comment 14 said that there was some verification that he had a patch that worked. Has a pref been created for Nightly users to test out on MacOS since then?
Assignee | ||
Comment 21•6 years ago
|
||
No it has not; I'm currently fixing the glitches from that patch and will provide an update once you can try out the pref.
Comment hidden (obsolete) |
Assignee | ||
Comment 23•6 years ago
|
||
Oops, that patch shouldn't have gone to this bug.
Updated•6 years ago
|
Comment hidden (obsolete) |
Comment hidden (advocacy) |
Assignee | ||
Comment 26•6 years ago
|
||
Renaming this bug because it's tracking more than just the elimination of the transparent surface.
Here's my current three-phase plan.
Phase I was the project to make Firefox use CoreAnimation at all. This phase is now concluding with bug 1491442 landing and the pref soon being turned on by default in bug 1574538. It does not improve power usage but lays the ground work.
Phase II is the project to improve Firefox power usage on macOS for the non-WebRender configuration. This phase is starting now.
Phase III will be about improving WebRender's power usage, so that WebRender can be turned on by default for Mac users.
The planned fixes will each help different browsing work loads:
- Some fixes, such as bug 1491448 and bug 1574586, eliminate general overhead.
- Some fixes, such as bug 1571551, will only help on web pages with expensive layer structures.
- Some fixes, such as bug 1491451 and bug 1491456, will help whenever only small parts of the window change.
There are also improvements we could make specifically to scrolling, and to video. But those changes are invasive enough that it's only worth implementing them for WebRender. So those will come in phase III.
Comment 27•6 years ago
|
||
Thank you so much for your effort. This is exactly the problem that is blocking me to use Firefox as my daily browser. It's simply unusable on my hardware.
I'm glad that there's finally someone who's working on this problem. I wonder if I could contribute in any form, but because I'm super new to the codebase, I can only watch the progress and perhaps doing some tests.
I know it's not going to be a simple fix, although I would appreciate if there is some possible ETA, thank you :)
Assignee | ||
Comment 28•6 years ago
|
||
Testing is actually the best way to help out at the moment! Just keep using Firefox Nightly as usual and report any bugs you see, by filing new bugs here on Bugzilla. The fixes that'll be landing soon have some risk of introducing visual glitches. So, if in the coming weeks you start seeing glitches such as elements that are cut off, or remnants of elements on the screen that should have disappeared, those are the things to be on the lookout for and report bugs on.
The other thing I'm planning to do is to add an indicator that moves every time we composite. WebRender already has such an indicator ("gfx.webrender.debug.new-frame-indicator"), but non-WebRender doesn't. Once we have such an indicator, I'd like to hear about websites which cause the indicator to keep moving even though nothing on the screen is changing. Then I can work on those cases and reduce their frequency.
I don't have a good ETA for this work but you can expect things to start landing on Nightly "soon".
Comment 29•6 years ago
|
||
@mstange - would it be possible to update this ticket once those changes actually landed so we could focus on this particular bug?
Assignee | ||
Comment 30•6 years ago
|
||
Yes, absolutely.
Assignee | ||
Comment 31•6 years ago
|
||
Call for help: If you're running 10.9, 10.10, 10.11, 10.13 or 10.15, and are interested in helping me out a bit with testing (unrelated to power usage), there are some instructions in bug 1576483 comment 1. Thanks!
Assignee | ||
Comment 32•6 years ago
|
||
important |
The first big power improvement has landed! The patch from bug 1491451 is in today's Nightly and should help with the power usage of small animations.
Comment 33•6 years ago
|
||
Works a treat. At highest scaled resolution on my 2013 MBP:-
-
With a blank Google doc just showing the pulsing cursor I now get about 8 hours predicted battery life vs about 2 hours before.
-
www.thetimes.co.uk now loads in about 7 seconds vs about 13 seconds before (I think because the Firefox tab throbber used so much GPU power that the CPU got throttled to a very slow speed to limit the CPU+GPU power dissipation)
In both cases the fan stays quiet whereas before it used to scream with extensive Firefox use.
Twice as fast for four times longer!*
*YMMV
Comment 34•6 years ago
|
||
I'm seeing something fairly similar to Mark - on a 13" 2015 MBP scaled to 1440x900, having a blank google doc open goes from 4.5 watts to 2 watts, and playing a youtube video at the default size goes from 5.5w to 4w. The baseline is around 0.5w, so that would be a 62% and a 30% reduction in power usage by Firefox, respectively.
Thanks for working on this!
Comment 35•6 years ago
|
||
Not as detailed as the above reports, but I wanted to give a huge thanks to Markus for fixing this. I'm now happily back on Firefox as my daily driver.
Comment 36•6 years ago
|
||
Looks good here too, just wanted to express how happy I am about this change. I suggest that you (or someone from Marketing) would write a blog post about this when it's "done" and definitely mention it in the Release notes with some percent, the press loves numbers :) This is such a positive news and might bring some people back from Chrome or Safari.
Comment 37•6 years ago
|
||
I'm seeing a huge improvement over here too (2015 13" MacBook Pro with scaled resolutions on internal display as well as external 4K display). Prior to this update I literally couldn't use Firefox because it would spin my fans way up and slow down my whole computer. Thank you, I'm very happy to finally see Core Animation being implemented.
I'm wondering, how far along are you in the implementation of these fixes? Also, will these move to the beta next week when it switches to version 70?
I agree - there should be a marketing push once this hits stable. The release of Firefox Quantum was bittersweet for Mac users. Firefox actually got worse for Mac users.
Comment 38•6 years ago
|
||
Also just want to confirm that this really helps, I can use FF again. Is this already in the FF70 dev edition?
Comment 39•6 years ago
|
||
(In reply to nkl from comment #38)
Also just want to confirm that this really helps, I can use FF again. Is this already in the FF70 dev edition?
I believe so, yes. You can look for the gfx.core-animation.enabled
pref in about:config
to confirm.
Comment 40•6 years ago
|
||
@Markus...
For me, on today's Nightly some animations seem broken, e.g. open a blank Google doc, the cursor doesn't animate. It does animate on today's trunk Firefox 69.0 & on Safari. I see the same problem on some other animations eg news throbbers.
Doesn't matter how I flip the coreanimation pref or gfx.webrender.all, animations are static
I think the same was true yesterday so I think for me the change occurred on Tues or Weds.
I don't have any non-default in about:config search for animations, but perhaps I monkeyed with something else?
Could this be related to the coreanimation stuff?
cheers
[ power consumption is remarkably low when nothing animates ;) ]
Reporter | ||
Comment 41•6 years ago
|
||
Mark, I still see an animating cursor on Google Docs on 10.13. What version are you on? Can you try to get a regression window using mozregression? https://mozilla.github.io/mozregression/
Reporter | ||
Updated•6 years ago
|
Comment 42•6 years ago
|
||
Same here. I also see the animations to behave as expected. I'm on the most recent nightly build. Weird!
Comment 43•6 years ago
|
||
Doh, an add-on called No Transitions had become active "all on its own" ;) It kills a lot of CSS transitions, I was using it to save power. All good now. Thanks for your time.
Reporter | ||
Comment 44•6 years ago
|
||
Mark, some additional improvements have landed in the 20190901094958 nightly. It would be valuable for you to retest and post your results.
Comment 45•6 years ago
|
||
Very impressive, most impressive is during page load where the tab throbber used to draw 20 W from the GPU leaving the CPU with only ~5 W to play with. In today’s build the GPU draws <<1 W leaving the CPU with ~12 W, it’s miles faster as well as cooler (used to be able to feel the machine base get hot even during a ten second page load)
all half brightness, max scaled resolution, I forgot to get GPU power from 2019-08-31 build, total power means whole machine including screen, memory, etc etc
CoreAnimation OFF 2019-08-31 build 2019-09-01 build Chrome 76
Guardian.co.uk small throbber 21 W total (10 W GPU) 10 W total (?? W GPU) 8 W total (0.2 W GPU) 7 W total (0.1 W GPU)
Scrolling mozilla.org 39 W total (18 W GPU) 35 W total (?? W GPU) 32 W total (12 W GPU) 32 W total (14 W GPU)
Blank google doc blinking cursor 30 W total (15 W GPU) 9 W total (?? W GPU) 7 W total (0.2 W GPU) 8 W total (0.1 W GPU)
Pretty competitive with Chrome, today’s build wins a couple of watts over yesterday’s, and with Quartz Debug I can see the partial present working - sweet!
Just for context my Mac has a new battery so 7 W total power is ~9 hours battery life, 30 W total power is ~2 hours.
Well done guys! And thanks a lot.
Comment 46•6 years ago
|
||
Markus, that sounds like something we may want to mention in our release notes? Thanks
Assignee | ||
Comment 47•6 years ago
|
||
We're putting the release note on bug 1574538.
Comment 48•6 years ago
|
||
I just tried the nightly build now, and already seeing very impressive performance and power improvements on my MacBook Pro 13-inch Retina 2014 with fullscreen, highest resolution. Just a very simple CPU and GPU usage test on my side also shows that the power usage is almost equal or even bit a less than Chrome 76.
I'll try to use this further as my daily browser, and see if there's any problem on webpages that I visit.
Thank you so much, great job! This should be widely noticed when it's landed on release, I'm feeling like FF Quantum finally became how it should been like when its firstly released.
Comment 49•6 years ago
|
||
I am using the nightly build for the past two days, and the performance is superb! After so many years, I have been able to use Firefox on my Mac - I used to test every Firefox release, and nothing had worked in the past.
My feedback is:
- I am using it as my primary browser, and it is stable, and with excellent performance. My Mac's CPU is heating no more :)
- I use an external non-Retina (1920x1080) monitor connected via HDMI. If I drag the window from Retina (Macbook) screen to my monitor (and vice versa), there is a flicker that's more pronounced than if I drag other applications.
Following is my configuration:
Locale: en-IN-IN
OS: 10.14.2
Mac Model: MacBookPro11,1 (13" Retina 2014)
CPU Type: Intel
CPU Count: 4
CPU Speed: 2.600000 GHz
RAM: 8.000000 GB
External: LG 22" 1920x1080
Monitor
Firefox: 70.0b3 (64-bit)
Thank you!
Comment 50•6 years ago
|
||
I usually try nightly builds every few weeks but end up going back to Edge Chromium or Chrome for speed and lack of heat. This makes my 2015 mbp without a dedicated dGPU become a power sipper compared to earlier builds. Thanks for landing these. I hope it gets a lot of press/attention.
Comment 51•6 years ago
|
||
Something in the latest Firefox update messed this up for me.
Watching a YouTube video on macOS Catalina + Brave 1.0.0 gives an energy impact of 10-20. Watching it on Firefox 70.0.1 gives an energy impact of 100-120 (!) just as it was before this patch.
Scrolling is the same story. If I go to the front page of Reddit and scroll up and down constantly, Brave gives an energy impact of ~18, Firefox jumps up to 120-140 (!!)
Reporter | ||
Comment 52•6 years ago
|
||
jvisser are you able to find a regression window using https://mozilla.github.io/mozregression/?
It would also be very helpful if you could record a profile with the gecko profiler. See https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler in how to use it.
Comment 54•6 years ago
|
||
I'll do both of those later today, and also use the Intel Power Gadget application.
I did some more preliminary testing. It seems (as expected if this patch isn't working properly for me) Retina displays disproportionally push up energy consumption.
With my Macbook docked and playing a 1080p60 YouTube video on my 1440p external screen I hit ~40 energy impact on Firefox 70.0.1; Playing the same video hits an energy impact of 2-5 on Brave 1.0.0, and 0,1 - 1 on Safari 13.0.3;
Doing the Reddit scroll test, Brave hits ~8 energy impact, Safari 10-13 energy impact, Firefox ~35 energy impact.
I also checked about:support to be sure, 'uses Tiling' and 'uses Tiling (Content)' are both true.
Comment 55•6 years ago
|
||
Okay, I didn't do regression testing but that's because apparently the patch never worked for me / was placebo (or perhaps one of the point releases of Catalina borked something?). I've only switched back to Firefox since 70.0.0 and testing that it still has the same massive energy use as 70.0.1; I also tried the newest Nightly (72.0a1), which also has the problem.
This a profiler run of a 1080p60 YouTube video:
https://perfht.ml/2qTXJh6
This is a profiler run of going to reddit.com, waiting 'till the page has fully loaded and then scrolling up and down in quick succession for a while:
https://perfht.ml/34Xpi7U
Both were run on a freshly made user profile without any extensions or about:config changes.
Reporter | ||
Comment 56•6 years ago
|
||
(In reply to jvisser from comment #55)
Okay, I didn't do regression testing but that's because apparently the patch never worked for me / was placebo (or perhaps one of the point releases of Catalina borked something?). I've only switched back to Firefox since 70.0.0 and testing that it still has the same massive energy use as 70.0.1; I also tried the newest Nightly (72.0a1), which also has the problem.
Can you report what kind Mac + GPU you're using, the resolution of the screen, and whether you have any scaling? Then please report intel power gadget numbers for 69 and 70.
Also are you playing the youtube video fullscreen?
Comment 57•6 years ago
•
|
||
FWIW I can confirm that Firefox (I only use Firefox Nightly) appears in the macOS list of apps with high energy impact again and the fans were unusually often loud the last few days.
(or perhaps one of the point releases of Catalina borked something?)
Could be a reason. I did a macOS update a few days ago (from a Catalina Beta to the latest stable release). I'll have to test with older versions of Firefox on the weekend to see if it also happens with these old versions.
I don't have any numbers but I can provide numbers on the weekend and specs of my MacBook later today. I am not playing youtube videos fullscreen, only in the regular size.
Comment 58•6 years ago
|
||
If it helps, I am still on Mojave and I don't believe I'm seeing this regression on FF 70.0.1
Chipset Model: Intel Iris Plus Graphics 655
Type: GPU
Bus: Built-In
VRAM (Dynamic, Max): 1536 MB
Display Type: Built-In Retina LCD
Resolution: 2560 x 1600 Retina
Watching a fullscreen youtube video on Firefox 70.0.1 produces the following energy impact:
Chrome: 30
Safari: 36
Firefox: 50
Comment 59•6 years ago
|
||
Similarly all is well here, Firefox still competitive with Chrome, Safari slightly better
Mojave 10.14.5
MacBook Pro (Retina, 13-inch, Late 2013) @ 1680x1050 scaled
Youtube video, not full screen (about 60% of screen area video rest is static)
Chrome
CPU ~4 W GPU ~1 W die package ~7 W, energy impact ~80
Firefox Nightly 72.0a1 (2019-11-15)
CPU ~5 W GPU ~1 W die package ~8 W, energy impact ~70
Safari
CPU ~ 2 W GPU ~1 W die package ~5 W, energy impact ~50
Comment 60•6 years ago
|
||
Seems like the regression started happening on Catalina.
Comment 61•6 years ago
|
||
I'm running Catalina and have not experienced the issue. FF Dev Edition, MBP Mid-2015 w/ integrated GPU.
Comment 62•6 years ago
|
||
Mac
MacBook Pro 13" Early 2015 (A1502)
Processor: 2.9GHz Dual-Core Intel i5
GPU: Intel Iris Graphics 6100 1536MB
OS: macOS Catalina 10.15.1 (19B88)
Scaling: 1440x900x2 aka 'looks like 1440x900' (physical screen resolution is 2560x1600)
Intel Power Gadget 'Power' approximate numbers
Firefox 70.0.1:
YouTube 1080P60 VP9 video - PKG 8 / Core 5,5
Scrolling this page - PKG 8 / Core 6
Firefox 69.0.3:
YouTube 1080P60 VP9 video - PKG 10 / Core 6
Scrolling this page - PKG 8 / Core 5
Brave 1.0.0 aka Chromium: 78.0.3904.97:
YouTube 1080P60 VP9 video - PKG 5,5 / Core 3,5 (even hits 2,9 at times!)
Scrolling this page - PKG 8 / Core 5
YouTube is not fullscreen and has a viewport of 672x378*2.00 (from 'stats for nerds')
Comment 63•6 years ago
|
||
Is there anything other informing/profiling I can do to help, Jeff?
Its kind of a bummer I (and probably a decent subset of users) still can't use Firefox properly because this patch isn't working and its still nuking our battery. I'd be glad to accelerate the fixing as much as possible!
Comment 65•6 years ago
|
||
Peak and average power usage of Firefox 71 looks to be slightly lower than Chrome 78 on MacOS 10.15.1 (I used Intel Power Gadget). The only thing that I noticed was that Firefox takes a bit longer than Chrome to reach idle power usage on some websites. Idle power usage is pretty much the same for Firefox and Chrome.
Macbook Air 2014 Non Retina.
Reporter | ||
Comment 66•6 years ago
|
||
jvisser, we have plans to improve things further but there are a couple of things that need to fall into place first. I'll try to remember to write here when we have more improvements complete.
Comment 67•5 years ago
|
||
Hey guys, just signed up on Bugzilla to post this here. I have some noob questions
- Is this available in normal release versions yet? Given that it's "status: ASSIGNED", I would assume not, but I'm not sure.
- Is there a way to verify this change is running, besides inferring it from a nightly build number or A/B testing battery life?
Thanks for the great progress on this, it's a game changer.
Comment 68•5 years ago
|
||
Just ran some more tests on 74.0, with the same settings as before:
1080P60 VP9 - PKG 7,5 / 5
Scrolling this page - PKG 8 / 5,5
As I forgot which YouTube video I used for the original test (my apologies) the small differences with Youtube are probably caused by the video being slightly less complex, especially since the scrolling test is virtually identical.
Jeff, did any of those improvements / refixes for this patch come to fruition for 71/72/73/74, or are other things taking priority right now (vs. battery drain)?
Reporter | ||
Comment 69•5 years ago
|
||
jvisser, can you try measuring Nightly 76 with gfx.webrender.all=true and gfx.webrender.compositor=true
Comment 70•5 years ago
|
||
FF 76a1 WR: PKG 5.8 / Core 3.3
Chromium 80.0.394: PKG 4.2 / Core 2.4
Same video and log length as https://bugzilla.mozilla.org/show_bug.cgi?id=1429522#c68
I also did a way more consistent test where I noted all my steps. In case more testing is needed, I and others (for comparison) can replicate it easily: clean profile with uBlock Origin, no background apps running, 1440 width window, viewport 966x543*2.00 and then a full power gadget log of https://www.youtube.com/watch?v=LXb3EKWsInQ in 1080P60 VP9
FF 74.0: PKG 10.6 / Core 7.5
FF 76a1: PKG 10.7 / Core 7.7
FF 76a1 WR: PKG 9.4 / Core 7.0
Chromium 80.0.394: PKG 8.3 / Core 6.2
FF 74.0 w/ forced MP4: PKG 7.4 / Core 4.2
FF 76a1 WR w/ forced MP4: PKG 6.6 / Core 3.6
Chromium 80.0.394 w/ forced MP4: PKG 8.7 / Core 6.5*
*h264ify probably broken on Chromium? Same values as VP9 despite hardware MP4 decoding
Comment 71•5 years ago
|
||
Hmm, it lost half my message (and I can't edit my already sent one). I hope this isn't considered spamming the thread. Anyway- long and short of it: damn good work guys! Those are pretty big improvements. I don't want to be overbearing but I genuinely appreciate the effort :) Is WebRender targeted for 76 on macOS, or is it a 'when its done' kinda thing?
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Comment 72•5 years ago
|
||
Is there any reason to keep this open still?
Assignee | ||
Comment 74•5 years ago
|
||
Ah, no, let's close it. The biggest improvements shipped with Firefox 70. Further improvements are unlocked by WebRender, which is tracked in the various wr-mac bugs: bug 1638378 (wr-mac-nightly), bug 1612506 (wr-mac-block), and bug 1479789 (wr-mac); for now, WR improves scrolling power usage over non-WR, and improvements for video playback are planned.
There are also some further ideas for reducing power usage (and some old outdated bugs) in the keywords:power os:macOS
bug list.
Updated•3 years ago
|
Description
•