You've mentioned a bunch of stuff, but even then the numbers don't add up double and triple buffering are adding just another few buffers per screen. Multiple buffers for every window still doesn't add up to the memory use levels some of these desktop environments use. 50 maximized windows with multiple buffers still ends under a gig.
Mipmapping on dynamic content is just daft. If you can generate mipmaps as they change without slowing things down then you can generate them on demand when they are needed.
The usual memory usage I was seeing was in the 200M-300M range -- this was on mutter/gnome-shell. As others mentioned, they can't reproduce the 1GB figure. But there was still a lot of noise about that, so I figured I'd explain where some of it is coming from.
> Mipmapping on dynamic content is just daft. If you can generate mipmaps as they change without slowing things down then you can generate them on demand when they are needed.
We do generate the contents on demand, but mipmapping requires the texture memory be available for the full chain. In theory, you can use sparse textures on OpenGL/Vulkan, but they have several drawbacks that make them unsuitable for compositor work -- changing the mipchain configuration for a single texture can often take 1-2ms, which wasn't fast enough for our performance targets. I did the investigation!
Mipmapping on dynamic content is just daft. If you can generate mipmaps as they change without slowing things down then you can generate them on demand when they are needed.