Dumb question: it seems like this assumes that once you have allocated a spot within an atlas, you can't move it. But wouldn't it be a within-GPU transfer to garbage collect a fragmented atlas into a new texture?
If so, then could you do a fast but messy allocation, then clean it up when you run out of space, or are about to? Or you could pull in more traditional GC tricks: have one texture that gradually accumulates long-lived images (the tenured region), and divide up another region into two semispaces that you do fast bump-like allocations into and then compact from one to the other when it fills up. You could even incrementally repack, assume copying within and between atlases works in the first place.
(I'm the author of the blog post) Yes, WebRender could repack it's texture atlases. A lot of stuff of various sizes go in there so I would not want to rely on repacking large amounts of pixels frequently but it could, among other things, help with more quickly converging back to a single texture atlas after an allocation spike. To my knowledge WebRender cannot move data within a texture using the OpenGL version it's restricted to.
Just wanted to let you know that you converged on the same solution (nested 1d allocators) that I came up with for Google Maps back in 2013ish.
We also made heavy use of allocation bitmaps and a few other tricks to ensure that the texture allocator does zero dynamic memory allocation at runtime, as that could cause performance bubbles.
Texture atlases are becoming a relic now that bindless rendering is a thing, but I suppose Firefox still has to be able to run on low spec Android devices with poor Vulkan support, or no Vulkan support at all. Maybe one day they'll finally get to follow game engines in deleting all of their atlas hacks.
Firefox's user base is also full of old Intel integrated GPUs that don't support bindless. The day WebRender can start relying on it cannot come soon enough but it's a long way off.
Texture atlases will still be a thing when you're dealing with thousands or tens of thousands of glyphs in a glyph cache (some languages end up with a combinatorial explosion of glyphs due to accent marks and stuff).
And Linux with no Vulkan support in many drivers, and macOS with no Vulkan support at all, and on all the Windows devices without Vulkan support... Vulkan is far from widespread still
D3D12 and Metal can do bindless as well, I mention Vulkan on Android because that's consistently the platform which lags the furthest behind everything else in real-world GPU feature support and driver quality.
If so, then could you do a fast but messy allocation, then clean it up when you run out of space, or are about to? Or you could pull in more traditional GC tricks: have one texture that gradually accumulates long-lived images (the tenured region), and divide up another region into two semispaces that you do fast bump-like allocations into and then compact from one to the other when it fills up. You could even incrementally repack, assume copying within and between atlases works in the first place.