Hacker News new | past | comments | ask | show | jobs | submit login

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.

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.

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?

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.

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.

Because of "Write once, deploy anywhere".

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact