Dramatically reduced power usage in Firefox 70 on macOS with Core Animation

Thank you for sharing these stats. They really seem significant!

Bitmex looks very interesting, any fun stories to share?

This will bring me back as well

> I've been nagging on HN's comment sections every few months about this issue whenever a FF related submission made the frontpage...

Same here, until one of the people responsible for the patches replied to tell me that he fixed it. I've been running nightly builds of Firefox ever since.

Firefox with NoScript runs fast and cool. I love it.

Do you have an FB number for improving the documentation here?

CALayer accepts a number of different data types for its contents property, IOSurface being one of them.

Another tip: CAShapeLayer draws on the GPU so simple shapes/strokes can be insanely faster drawn that way vs CoreGraphics.

It's "documented" as in "tweeted out by an Apple engineer": https://twitter.com/bciechanowski/status/874345241666437120?...

One thing that is not documented is that the IOSurface must have been created with the 'BGRA' pixel format, or it will silently render as black instead.

> So we end up in a situation where using the most efficient way to display contents now relies on undocumented/private APIs. At any point Apple can break them, or punish us for using them.

Unless Apple wants to break all browsers, that is. At least Chrome and now Firefox use it.

It's not a private API, the docs are just out of date. You can technically set any object as the contents of a CALayer (the property's type is `id` or `Any`), it's just that most objects won't do anything productive.

The docs call out using images specifically because that's the 99% use-case; they need to be updated saying that `IOSurfaceRef`s can be used as layer content as well.

`IOSurfaceRef` itself was actually private at one point, IIRC, but isn't anymore.

In addition to battery life, I'd also like things like native PiP mode (if possible) and native, fullscreen video playback. Better rendering gets closer to letting Firefox replace Safari for me, but the other features are important to me, too.

I think they would need to fully adopt CALayers to get all of the way down to Safari's power usage.

>This proposal is a bit hacky. The more pure solution would be to teach the compositor to create CoreAnimation layers for Gecko layers, so that for example the throbber animation gets one CoreAnimation layer that contains all the animation frames in a film strip, plus an offset and clip that only shows the current frame. (That's how the Gecko layers are set up for the throbber animation.) Such a solution would be preferable but it would require much more work in the compositor. The tiling solution that I'm proposing in this bug is easier to implement and a bit more generic, because it treats CompositorOGL compositing as a black box that just produces a framebuffer filled with pixels, along with an invalid region.

https://bugzilla.mozilla.org/show_bug.cgi?id=1491456

If I am following this correctly, when dealing with a small on-screen animation, they are moving from having to repaint the whole window to only repainting a largish chunk of the window.

Adopting CALayers at a deeper level in Gekko would allow them to only update the animation itself.

Doing so would require a good deal of additional work.

Is there a version of this for chrome?

I went back to Safari after bouncing between Chrome and FFX and I’m so happy there. It’s quite a bit faster and uses far less resources.

Activity Monitor does decent tracking of power consumption. If you can remember to switch browsers at regular intervals, you should be able to get meaningful measurements.

I think maybe Mozilla developers should not waste their time to support poorly documented proprietary platform with very low market share.

You can enable PiP mode on Firefox - in `about:config` look at the `picture-in-picture` options.

I'm not a normal Firefox user — I usually use Chrome and Safari side-by-side. So I decided to give FF another try with this release, and I agree that the scrolling performance is noticeably worse in FF than Safari and Chrome on the same page. I know the link here is about power usage, not performance, but it makes things feel much less nice.

In theory, yes, via the XPRESENT extension and similar mechanisms on Wayland. I don't know how well the drivers and window server optimize it though. (I plan to investigate this at some point.)

Firefox on Linux, we remember, is the browser that has software ffmpeg video decode. If you're looking for battery life, you better find some script that can pipe YouTube to VLC and an ad-blocker that allows you to block all videos, all of them.

And, well, then you are probably still using X server with various terrible extensions that are either polluting the graphics card with constantly composing windows as fast as it will go or, not entirely unlikely, doing CPU blits of window buffers. Just to produce an artifact-riddled not-Vsynced mess.

I thought it would've been informative to show Safari in the charts.

Safari is unfortunately still consuming far, far less power on my Mid 2012 MBP and my 2017 MBP - though there is a significant improvement. Others have posted exact statistics.

Open the About Firefox menu item and there's a button there to update.

Stream video playback would probably invalidate most of the framebuffer anyway, so I'm not sure how much it would help. It's possible it will make a difference but probably not much. There are other things they could do along these lines that would definitely help, though.

Deprecated, I thought. Just there for legacy support

Core Animation Layers do allow you to mark a layer or only a portion of a layer as needing an update.

https://developer.apple.com/documentation/quartzcore/calayer

Taking advantage of this would require deeper changes in Gekko than this initial change.

https://bugzilla.mozilla.org/show_bug.cgi?id=1491456

Perhaps WebRender will do a better job of leveraging the possibilities of the native platform APIs for the various lesser used platforms?

In any event, it's a huge amount of work to land a change which makes such a huge difference in battery life, and that work is appreciated.

I think the author is incorrect: flushBuffer is ~20 years old. The "corresponding API" in Windows is not OpenGL, and Apple also has analogous modern APIs which handle dirty regions efficiently.

Of course Apple has a partial window update API which is the primary drawing mechanism. flushBuffer maps to OpenGL, and Windows has its own version of this too (Wingdi::SwapBuffers).

I agree that browsers using OpenGL is...a design you could reach when measuring for graphics throughput at the expense of all else.

Using Linux, I can't watch youtube or use Google Hangouts for too long before the fans start going. Google refuses to add GPU support for Linux/Chrome. It's annoying.

https://blog.astropad.com/the-catch-22-of-apple-apis/ seems relevant

It won't hurt, but the article pointed out the main performance fail was coming from all the increased strain that retina displays were causing on memory and cache. Since retina displays have 4x as many pixels, Firefox was doing 4x as much work for its inefficient compositing engine doing large full-scene copies on every frame, and this was pushing the limits of what typical integrated graphics was able to smoothly pump through bandwidth-wise.

Yes, it will help, but the memory bandwidth savings decrease quadratically as DPI decreases, which is why you aren't seeing much of an impact.