1429522 - Improve compositing power usage on macOS by using CoreAnimation

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Jeff Muizelaar [:jrmuizel]]

Transparent windows use too much power. See bug 1422090 and bug 1404042.

Comment 1

[Mark]

I wanted to give some feedback on the transparency & Core Animation issues from some tests I’ve been running. I wanted to measure the performance improvement of "opaque Firefox” and guess at how Core Animation might improve things further, by looking at Chrome with and without Core Animation.

(If you haven’t read bug 1422090 where this started, you’re probably not used to my immensely long posts. Sorry.)

I’ve got a very early Retina MacBook Pro so I presumably have the weakest Retina CPU+iGPU package (excluding MacBooks)

Note 1 gives details about CPU throttling and possible benefit of Core Animation (based on testing Chrome)

Turning off transparency and the tab throbber substantially reduces Firefox’s power consumption and prevents most fan noise even at the highest resolutions. It also prevents the huge page load slowdown at high scaled resolutions which happened when my CPU got drastically power starved by the GPU. But my fan will still spin up on repeated page loads at 1680x1050 because my GPU is still working pretty hard during page load (it seems to paint the whole Firefox window at ~30 fps as the content builds), and the CPU still gets somewhat power starved presumably by the GPU. But the page load slowdown is tens of percent rather than the hundreds of percent I was seeing with transparency enabled.

With transparency & the tab throbber disabled, watching a page load @ 1680x1050 on Intel Power Gadget logging I can see the CPU running at Turbo Boost, 2900 MHz, 12 W power for the first few tenths of a second, until (presumably) first paint, then the GPU power dominates as the page content builds and gets repeatedly painted. During this latter part of the page load the CPU gets power starved to 2400 MHz and ~7 W.  Using Quartz Debug > Flash Screen Updates I can see that the whole Firefox window is being updated like crazy throughout this part of the page load.

Animating at 1680x1050 scaled & 60 fps is still very challenging for my GPU even with "opaque Firefox" so continuous scrolling or on-page animations of any size consume a lot of power and get the jet engine fan going.

“Opaque Firefox" has page load and scroll power consumption broadly similar to Chrome with Core Animation disabled using —disable-mac-overlays. When I use Quartz Debug > Flash Screen Updates I can see Chrome —disable-mac-overlays updating the whole screen like crazy during page load, similar to Firefox. Which leads to power consumption similar to “opaque Firefox".

When I enable Core Animation in Chrome I see a substantial reduction in power consumption during page load. When I use Quartz Debug > Flash Screen Updates I see that the updates are piecemeal, a checkerboard of update flashes as different areas get updated only as needed. Full page scrolling is still very hard work for my GPU, but with Core Animation enabled, Chrome gets better fps with somewhat less GPU power. So I hope the same will be true for a “future Firefox” with Core Animation. (Of course I don’t if your Core Animation solution will be like Chrome’s).

Note 2 gives some data on battery life with and without transparency, and a guess at what Core Animation might do.

At my normal 1440x900 resolution with the 60 fps throbber enabled, "opaque Firefox" is a pleasure to use and doesn’t spin up my fan at all. The GPU rarely goes over 4 W. Transparent Firefox was awful, the GPU went up to 16 W and everything slowed down and got hot. Faster, cooler, battery lif-ier! I measured battery life for a page with a continuously running slideshow carousel and put the results in Note 2. Getting rid of transparency has given a big boost to battery life. I think Core Animation will do even more, particularly at high scaled resolutions. I think that Core Animation might make battery life much less dependent on scaled resolution. And at 1680x1050, based on Chrome with & without Core Animation, “future Firefox” might get double today’s battery life?????? YMMV

Of course WebRender is another story - it’s still a resource monster so turning it on more or less offsets the benefit of the opaque Firefox window!

I think fixing transparency & adding Core Animation to Firefox will make really dramatic improvements to Firefox's power consumption on Mac, prevent page load slowdown at high scaled resolutions, and perhaps improve scrolling fps at high scaled resolutions. Even on my anaemic Retina MBP.  


Note 1:- CPU & GPU power

1680x1050 resolution, full screen browser window, loading www.theguardian.com/uk (a fairly complex page), MacBook Pro 11,1, MacOS 10.13.3

Firefox Nightly; disable transparency and throbber using browser.tabs.hideThrobber TRUE and gfx.compositor.glcontext.opaque TRUE
    loading:- 
      Intel package draws ~27 W, CPU is power starved, page load is somewhat slow:- ~18 W GPU, ~6 W CPU, page load ~3 sec
    scrolling:- 
      ~18 W GPU, 50 fps, some jank

Chrome --disable-mac-overlays to prevent Core Animation (perhaps broadly comparable to Firefox Nightly as above)
    loading:- 
      Intel package draws ~27 W, CPU is power starved, page load is somewhat slow:- ~18 W GPU, ~6 W CPU, page load ~3 sec
    scrolling:- 
      ~18 W GPU, 50 fps, some jank

Chrome default settings, Core Animation is enabled (perhaps broadly comparable to “future Firefox with Core Animation"?)
    loading:- 
      Intel package draws ~17 W, CPU is not starved, page load is fast:  ~6 W GPU, ~11 W CPU, page load ~2 sec
    scrolling:-
      ~15 W GPU, 60 fps, noticeably smoother than above

I used Intel Power Gadget & iStat Menus to get powers; Quartz Debug to get fps.


Note 2:- battery life

Full screen browser window at various resolutions, loading bug 1419079 attachment 1 [details] [diff] [review] and leaving its slideshow carousel running. Screen 50% brightness,  MacBook Pro 11,1, MacOS 10.13.3

Battery life in hours, approx
                                           1440x900     1680x1050

Firefox, default, transparent window         4.5            3
Firefox, opaque window                       6              4.5
Chrome, Core Animation disabled              6              5
Chrome, Core Animation enabled               7              7

YMMV, particularly depending on content being displayed.

Comment 2

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch.

Proposed patch attached.

I've verified that this patch works with both regular OMTC layers and WebRender. The main issue remaining is that resizing is ugly. (It works, but it's racy during the actual resize process.)

Feedback is appreciated.

Comment 3

[Mark]

Do you have a Try version with this patch? I would like to have a look at power consumption & performance. Thanks.

Comment 4

[Timothy Nikkel (:tnikkel)]

Try push
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d41538bef16cd7d6e79bdd5f9926a955cd4b0734

Comment 5

[Timothy Nikkel (:tnikkel)]

Try push that actually builds
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7b875fd41f2a488b0f329b9ee4b74e8b2b657330

Comment 6

[Mark]

TL;DR

This Try doesn’t behave at all like I expected. Perhaps I misunderstood or am using it wrong. It’s weird.

Quartz Debug reports the Try window as opaque regardless of gfx.compositor.glcontext.opaque setting, I expected it to toggle opaque/transparent.

But the GPU power consumption is as though the Try build window is always transparent regardless of gfx.compositor.glcontext.opaque setting, I expected low GPU power consumption with the Try window set opaque and high with it set transparent.

And I don’t see the ability for the MacOS compositor to just animate small areas of the Firefox Try window, e.g. throbbers. Quartz Debug shows the whole Firefox Try window updating even when only a small animation (e.g. a throbber) is running. I expected Core Animation to mean that small animations only required only small areas of the screen to be updated, like Chrome. Not the case, so the Try still has very very high GPU power consumption compared to Chrome when animating small screen regions at high scaled resolution. 

This is all with WebRender OFF but I had a quick look and think the same is true with it on.


Long version

1) The Try window seems always opaque regardless of gfx.compositor.glcontext.opaque setting

Quartz Debug > Tools > Show Opaque Regions ticked

gfx.compositor.glcontext.opaque        Nightly 2018-09-12                 Try build
TRUE                                 shows up green - opaque       shows up green - opaque
FALSE                                shops up red - transparent    shows up green - opaque

Not what I expected, I expected gfx.compositor.glcontext.opaque to toggle green/red (opaque/transparent) on the Try build too.

Quartz Debug > Tools > untick Show Opaque Regions


2) But the GPU power consumption is as though the Try build is always transparent regardless of gfx.compositor.glcontext.opaque setting 

scrolling mozilla.org, full screen window, 1440x900 scaled resolution, MacBookPro11,1, GPU power from iStat Menus

gfx.compositor.glcontext.opaque        Nightly 2018-09-12                 Try build
TRUE                                        4 W                               15 W 
FALSE                                      15 W                               15 W

Not what I expected, I expected to see the Try build have low GPU power consumption with gfx.compositor.glcontext.opaque TRUE, like Nightly. The GPU power consumption results also seem to contradict the Quartz Debug results in (1) above:- if the Try window is opaque regardless of gfx.compositor.glcontext.opaque setting, shouldn’t the GPU power consumption always be low??


3) the whole Try window seems to still update however small the animating region

Quartz Debug > Tools > Flash Screen Updates 

whole window flashes while the tab throbber throbs

whole window flashes when the tiny live-pulse throbber is visible on attachment 8962814 [details]

attachment 8962814 [details] on Chrome shows just the tiny rectangle containing the live-pulse animation updating, Firefox Try shows the whole window updating. Chrome GPU power @1440x900 is <<1 Watt vs Firefox Try ~15 W (!!). Likewise the Firefox Try tab throbber still destroys the GPU and throttles my CPU at high scaled resolution, partly I think because issue (2) but also because issue (3) the whole window updating works the MacOS compositor too hard (IIUC?).  

I thought the idea with Core Animation was to allow the MacOS compositor to just update the small changing areas of the screen, not the whole thing?? 

cheers

Comment 7

[Markus Stange [:mstange]]

Thanks for testing this, Mark, but please be aware that this patch is only the first step. Using CoreAnimation will let us update parts of the window eventually, but only once we use different layers for different parts. The first step is just to get something running with a single layer that covers the entire window.

> 1) The Try window seems always opaque regardless of gfx.compositor.glcontext.opaque setting

You're right, the gfx.compositor.glcontext.opaque pref is ignored by the current patch. We should update the patch so that setting the pref causes us to call setContentsOpaque:YES on the CoreAnimation layer.

Another thing that's worth pointing out is that current vanilla Firefox does not have a transparent *window* - the bug summary is inaccurate. Instead, what happens is that Firefox publishes two *surfaces* to the window server:
 1. An opaque window surface (opaque except for the rounded corners), which is mostly black
 2. A transparent OpenGLContext surface on top of that, which contains the actual window contents.

The red that you see in Quartz Debug is the red from the OpenGLContext surface. If the OpenGLContext surface had holes in it you would see green highlighting from the opaque Firefox window underneath.

The power-wasting aspect of this is that the window server blends the OpenGLContext surface into the window surface on every composite for all pixels of the window, even though the OpenGLContext surface mostly contains opaque pixels. Setting gfx.compositor.glcontext.opaque to true eliminates this blending step because it turns the OpenGLContext *surface* completely opaque.

With CoreAnimation, we no longer publish two separate surfaces to the window server. Instead, we publish a CoreAnimation layer tree, which gets treated as one surface by the window server and only gets one highlighting overlay: green for the whole window, because the window itself is considered to be opaque.
This doesn't mean that the blending step is eliminated, though. The CoreAnimation layer tree still consists of multiple layers that need to be blended with one another. In order to eliminate this blending step, it's the *layer* that needs to be marked as opaque, and the window server does not seem to have a way of highlighting opaque or transparent *layers*, as far as I can tell.

Comment 8

[Mark]

Thanks Markus. As usual it's all much much more complicated than I realised. Who knew browers were so complicated??? I appreciate you taking the time to educate me.

I guess my (very blunt) comment would be:- if the aim of the patch is as stated "... a large battery life win" [by reducing GPU power at high scaled resolution] it doesn't work for me. The Try version uses lots of GPU power @1440x900 just like default "transparent" Firefox. Nightly set to "opaque" uses substantially less GPU power.

I expect I've misunderstood in which case apologies for my bluntitude and for taking your valuable time :)

Comment 9

[Mark]

I was just looking at the GPU load using Activity Monitor > Window > GPU usage   - the moving histogram.

If anything the Try build loads up my GPU more than vanilla "transparent" Nightly. Just counting the little blue squares on the histogram while scrolling mozilla.org @1440x900:- the Try uses about 15 squares vs around 6 squares for vanilla "transparent" Nightly.  I am not sure what the connection is between little blue squares and GPU power in watts, it seems quite subtle.

I also looked at FPS in Quartz Debug > Window > FrameMeter while scrolling mozilla.org at 1680x1050 and "transparent window" Nightly managed ~45 fps, the Try only managed ~35 fps. In both cases my GPU was melting at nearly 20 W.

So for me the Try is a step backwards from vanilla "transparent" Nightly in terms of GPU load & power. YMMV I guess.

I've probably misunderstood again, apologies in advance!

Comment 10

[Markus Stange [:mstange]]

Comment on attachment 9008569 [details] [diff] [review]
Proposed patch.

Review of attachment 9008569 [details] [diff] [review]:
-----------------------------------------------------------------

I haven't tested this, but the code looks good, as far as it goes. The commit message is rather inaccurate, though, see my other comment on this bug and Mark's findings.

I've filed a few bugs for the sub-steps that I have in mind for fixing this bug completely. Can you move this patch to bug 1491442 and put the important changes behind a pref check?

Comment 11

[Mark]

Sounds complicated

Can I strongly suggest:-

You guys at Mozilla should implement a Mac power consumption test protocol, particularly focused on the GPU. It sounds like some of the earlier bugs in your sequence won't change power consumption much, but I think you should get in the habit of running some standardized power tests each time you address one of these bugs.

A standardized test might be:- portable Retina Mac, speed scrolling mozilla.org full screen at different scaled resolutions, look at CPU and GPU power in [power app]. Then flip your pref or apply your patch and repeat. 

[power app] could be Intel Power Gadget but iStat Menus is nicer, it breaks out GPU power clearly and always runs in the menu bar.

I think you could do with some more subtle tests too. And across a range of machines say an early Retina MBP like mine; a fanless ULV MacBook; and maybe a high end rMBP with a dGPU; etc?

Don't rely on Some Guy on the Internet (me) to do your power testing. It's too important. I am just a slacker liable to wander off and lose interest. Or I could go under a bus.

And to emphasise:- by power I mean actual watts, not a proxy like ms on the GPU or blue squares in Activity Monitor. They're good too, but this is all about actual power out of the battery and into the heatsink. If a patch doesn't reduce watts, don't implement it. Watts watts watts watts watts.

Comment 12

[Markus Stange [:mstange]]

We're not relying on you to do our power testing, don't worry.

Comment 13

[Mark]

I always worry.

Another good power test would be a small throbber on a static background. But you know that.

Comment 14

[Patrick Walton (:pcwalton)]

I have a new version of the patch that makes the layer opaque and also fixes the resizing issues. Some quick verification seems to show that the power consumption when scrolling is significantly reduced with that.

I will post it once I have it updated to go behind a pref.

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Any chance of landing this for 64? Or do you think it is better to wait to land it in 65 (and then consider uplift)

Comment 16

[Markus Stange [:mstange]]

This is not going to be in a state to turn it on for users in time for 64.

Comment 17

[Gorjan Jovanovski]

Any updates on this?

Comment 18

[Markus Stange [:mstange]]

Work has begun.

Comment 19

[charlie.siegel]

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

Work has begun.

Excellent! That's great news. Thank you.

Comment 20

[mb]

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?

Comment 21

[Markus Stange [:mstange]]

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 22

[Markus Stange [:mstange]]

Attachment: Bug 1533562 - Remove code that deals with non-rounded bottom corners on regular windows. r?spohl

Rounded bottom corners have been the default since 10.7.

Depends on D22642

Comment 23

[Markus Stange [:mstange]]

Oops, that patch shouldn't have gone to this bug.

Comment 24

[Phabricator Automation]

Comment on attachment 9049417 [details]
Bug 1533562 - Remove code that deals with non-rounded bottom corners on regular windows. r?spohl

Revision D22643 was moved to bug 1533562. Setting attachment 9049417 [details] to obsolete.

Comment 25

[p3zbqj3v.eff]

Are there any updates on this? I had to switch back to Chrome because of this bug.

Comment 26

[Markus Stange [:mstange]]

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

[soya_daizu]

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 :)

Comment 28

[Markus Stange [:mstange]]

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

[wojtek]

@mstange - would it be possible to update this ticket once those changes actually landed so we could focus on this particular bug?

Comment 30

[Markus Stange [:mstange]]

Yes, absolutely.

Comment 31

[Markus Stange [:mstange]]

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!

Comment 32

[Markus Stange [:mstange]]

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

[Mark]

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

[bgstandaert]

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

[kwang.m.yi]

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

[Patrick Albrecht]

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

[charlie.siegel]

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

[nkl]

Also just want to confirm that this really helps, I can use FF again. Is this already in the FF70 dev edition?

Comment 39

[Bobby Holley (:bholley)]

(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

[Mark]

@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 ;) ]

Comment 41

[Jeff Muizelaar [:jrmuizel]]

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/

Comment 42

[kwang.m.yi]

Same here. I also see the animations to behave as expected. I'm on the most recent nightly build. Weird!

Comment 43

[Mark]

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.

Comment 44

[Jeff Muizelaar [:jrmuizel]]

Mark, some additional improvements have landed in the 20190901094958 nightly. It would be valuable for you to retest and post your results.

Comment 45

[Mark]

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

[Pascal Chevrel:pascalc]

Markus, that sounds like something we may want to mention in our release notes? Thanks

Comment 47

[Markus Stange [:mstange]]

We're putting the release note on bug 1574538.

Comment 48

[soya_daizu]

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

[Vivek Kapoor]

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

[atiensivu]

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

[jvisser]

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 (!!)

Comment 52

[Jeff Muizelaar [:jrmuizel]]

jvisser are you able to find a regression window using https://mozilla.github.io/mozregression/?

Comment 53

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

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

[jvisser]

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

[jvisser]

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.

Comment 56

[Jeff Muizelaar [:jrmuizel]]

(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

[Sören Hentzschel]

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

[James Agnew]

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

[Mark]

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

[nkl]

Seems like the regression started happening on Catalina.

Comment 61

[bintoro]

I'm running Catalina and have not experienced the issue. FF Dev Edition, MBP Mid-2015 w/ integrated GPU.

Comment 62

[jvisser]

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

[jvisser]

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 64

[Mike Conley (:mconley) (:⚙️) (PTO July 21 - 25)]

ni?ing for comment 63.

Comment 65

[sheelgautam995]

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.

Comment 66

[Jeff Muizelaar [:jrmuizel]]

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

[Alexander]

Hey guys, just signed up on Bugzilla to post this here. I have some noob questions

1. Is this available in normal release versions yet? Given that it's "status: ASSIGNED", I would assume not, but I'm not sure.
2. 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

[jvisser]

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)?

Comment 69

[Jeff Muizelaar [:jrmuizel]]

jvisser, can you try measuring Nightly 76 with gfx.webrender.all=true and gfx.webrender.compositor=true

Comment 70

[jvisser]

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

[jvisser]

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?

Comment 72

[Jeff Muizelaar [:jrmuizel]]

Is there any reason to keep this open still?

Comment 74

[Markus Stange [:mstange]]

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.