4 ms·

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 missin

by brians 7y 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?

princekolt 7y ago
Because of "Write once, deploy anywhere".
pcwalton 7y ago
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.
mstange 7y ago
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.

by brians 7y 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?

princekolt 7y ago

Because of "Write once, deploy anywhere".

pcwalton 7y ago

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.

mstange 7y ago

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.