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

This is quite dramatic, in that I can actually <i>feel</i> my Macbook not heating up as much, nor can I hear the fans anymore.<p>We do quite a lot of work on a trading website that has heavy use of Canvas and CSS animations, and the latter really kills performance. Two runs on our production website from Intel Power Gadget, pre and post upgrade, show decreased temperature, a lot fewer power spikes, less DRAM wattage, lower GFX clocks, and about 40% less power overall:<p>Before: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;WkdWaHx.jpg" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;WkdWaHx.jpg</a><p>After: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;3ojMyjT.jpg" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;3ojMyjT.jpg</a>

I&#x27;ve been nagging on HN&#x27;s comment sections every few months about this issue whenever a FF related submission made the frontpage... Now I can finally ditch chrome and start spreading the news so the guys in my office can do it too :D<p>Even better is the news that it&#x27;s going to improve even further, and the plans to include a Metal backend to WebRender...

Amazing work by my colleagues! I hope we&#x27;ll not regress this with WebRender ;)<p>Celebration aside, one particular note (that was known, but still) makes me sad:<p>&gt; It’s worth noting that the ability to assign an IOSurface to the CALayer contents property is not properly documented. Nevertheless, all major browsers on macOS now make use of this API.<p>So we end up in a situation where using the most efficient way to display contents now relies on undocumented&#x2F;private APIs. At any point Apple can break them, or punish us for using them.

What I want is an <a href="https:&#x2F;&#x2F;arewesafariyet.com" rel="nofollow">https:&#x2F;&#x2F;arewesafariyet.com</a> that tracks Firefox&#x27;s macOS energy usage against Safari&#x27;s so that I can figure out when to switch. As far as I can tell, they still have a long way to go to match Safari in battery life and it would be nice if they had an explicit tracker set up as a way of prioritizing fixing that.

This is very good news!<p>Firefox has been my daily driver for well over a year now and I&#x27;ve been extremely happy with it. The gripe I&#x27;ve had has been the heat&#x2F;power consumption.<p>Props to the dev team!

This is great to see! One gripe I still have with Firefox is how poorly it handles video playback (controls and energy consumption) compared to Safari. This makes me want to use Firefox more often, but Safari will still remain my daily driver because of native full screen video and PiP mode.

Just downloaded a clean install of Firefox 70 but even scrolling a simple site like Hacker News feels very laggy compared to Chrome.<p>Not sure whats going on. 2018 Retina MBP with dedicated GPU running Catalina.

Just if someone wonders: &quot;Tagesschau&quot; is a german television news service, probably the most famous in Germany.

Cool! I&#x27;ve been curious about Firefox&#x27;s progress over the last few years, but this is what pushed me to download a modern version. Good work, Firefox team!

So OpenGL wasn&#x27;t allowing partial viewport &quot;dirtying&quot; on macOS. Does that mean Firefox on Linux has an opportunity for a similar gain?

Anyone has insights how power usage compares to safari? I’m team safari for the past years because it’s just so much easier on the battery than anything else

Does this help with streaming? In particular I have always had issues with twitch and firefox.

Good changes, although I find it amusing&#x2F;discouraging that the &quot;high complexity&quot; graphics use case is a word processor.

Can&#x27;t wait to compare this to Safari, which I don&#x27;t like but is dramatically gentler on my macbook&#x27;s battery.

&gt; The crucial limitation here is that flushBuffer gives you no way to indicate which parts of the OpenGL context have changed. This is a limitation which does not exist on Windows<p>Sigh.<p>The state of OpenGL on OSX is terrible.

&gt; The crucial limitation here is that flushBuffer gives you no way to indicate which parts of the OpenGL context have changed.<p>Partial window updates have been available in Windows since long ago (in non-accelerated GDI). Why don&#x27;t others just copy Windows API instead of inventing their own poor API?<p>Maybe there is no partial updates because an application can write directly to GPU textures and GPU will redraw entire screen anyway?<p>Also I am not sure that browser needs OpenGL, because you cannot render text efficiently on GPU anyway and the main content of web pages is text.<p>&gt; Whenever a layer is mutated in any way, the window manager will redraw an area that includes the bounds of that layer, rather than the bounds of the entire window.<p>Then the problem still isn&#x27;t solved because a layer can be much larger than changed pixels.

Wonderful, can&#x27;t wait to test it out. This is one of the main reasons I still use Chrome. I can&#x27;t watch videos on my laptop without hearing my fans go crazy when using FF

I don&#x27;t know any details, but Chrome canary on MacOS has a &quot;metal&quot; flag.<p>&quot;Vulkan&quot; flag on Android too.<p>(Post mentioned they plan on implementing metal backend)

Isn’t it worrisome the dependence on OpenGL when it’s been deprecated by Apple in favor of Metal?<p>Are there any plans to move of off this API?

Really exciting. This was the one thing keeping me from using Firefox on my personal laptop.

How long till we get video acceleration?

How does it compare to Chrome?

Seems like a wash to me on a non-retina mac. It was fine before and seems fine now. Does anybody know if this should theoretically help non-retina mac users?