Hacker News Reader

Comment by vbezhenar | Hacker News Reader

How does one optimize applications for power usage? Should it avoid using GPU? Should it run computations in batches?

The main change in Firefox is to use the system compositor (via CoreAnimation) to composite components of Firefox windows. Until just recently, Firefox composited its entire window into a buffer using OpenGL, and then sent that to the system compositor. Unfortunately, with that method, you have to send the entire window to the system compositor on every frame (because the APIs are just limited that way), which uses a lot of power when just one little caret is blinking, for example. With CoreAnimation you can set things up so that large chunks of the window that aren't changing never get recomposited.

Unfortunately this change is somewhat invasive, which is why it wasn't done long ago.

Long ago? That is what enabled the original Mac GUI in the 1980s. I am having trouble understanding why anyone would have shipped anything else—what was missing in the time of earlier Firefox?

Because of "Write once, deploy anywhere".

Core Animation wasn't integrated into the OS window server until somewhere around Mac OS X 10.7. Before then, Core Animation on Mac OS X ran in your own process, so there wasn't really an advantage to using it over just doing your compositing yourself.

APIs for partial compositing in combination with hardware accelerated compositing was the thing that was missing. If you don't use hardware accelerated compositing, repainting only part of the window, and letting the system compositor know about those areas, is not a problem. It's only the GPU acceleration and the lack of convenient APIs that makes this a problem.

Before Firefox got hardware acceleration, so up until Firefox 3.6, we were using CPU-side painting and sending accurate dirty areas to the windowing system. With Firefox 4, we added hardware accelerated compositing, which made scrolling and transform / opacity animations a lot more performant. However, it also meant that we switched to using OpenGL for the compositor, and macOS does not expose any APIs for invalidating only parts of an OpenGL context. And at the time Firefox 4 shipped, "retina" displays were not a thing yet, so the impact of recompositing the entire window was not apparent. And there was the pervasive notion that "modern GPUs are fast, fill rate is not a problem". It was only as pixel count grew and grew that this started becoming problematic. And it took some amount of research and a lot of surgery to switch Firefox to an approach that gets OpenGL content to the screen while also allowing for partial updates of that OpenGL content.

Additionally, you can avoid using a transparent window this way, which means that the window server doesn't have to draw stuff behind the main Firefox window. You can do this with the old compositing method too, but you lose the rounded window corners and the vibrancy effect.

In Firefox in particular they've changed how animations are done, for instance removing transparency where it wasn't needed https://bugzilla.mozilla.org/show_bug.cgi?id=1429522#c26

In general you want to

- do less work (e.g. don't do unnecessary work, cache results)

- do it less often (coalesce the work you have so the machine can go into deeper idle states)

- do it more efficiently (e.g. do graphics on the GPU instead of CPU)

It seems they are actually using the power-not-hungry GPU more. From the v69 release note:

> For our users on macOS, battery life and download UI are both improved: macOS users on dual-graphics-card machines (like MacBook Pro) will switch back to the low-power GPU more aggressively, saving battery life.

https://www.mozilla.org/en-US/firefox/69.0/releasenotes/

Reply on news.ycombinator.com