Just to remind people here: a single uncompressed "4k" picture is 33MB. Have your compositor hold 10 of them and you get 330MB just for the window images.
Across multiple monitors my desktop is 6400x2160, which at 32 bits comes to 55MB.
Considering memory is slow and GPU compute these days is cheap maybe it would make sense to relayout and rerender things each frame directly into screen buffer instead of keeping the window surface buffers resident. That would require rewriting quite a lot of things though.
You need window surface buffers in order to do seamless compositing, scaling etc. It's quite technically possible to achieve pixel-perfect 2D rendering with GPU-side compute, but in many ways it's still an open problem.
Scaling is for legacy apps, right? Modern apps should get the area to render and the desired pixel density.
Not sure what you mean specifically by "need" in "need ... to do compositing". Compositing is just a way (e.g. rerender only on changes, cache results) of running a desktop environment. Strictly speaking you don't need compositing, you can just use immediate mode across the DE and apps.
The tradeoff of course is that if an app is lagging you get a blank rectangle instead of a frozen picture. Well not quite 0 or 1. You can cache lowres and/or compressed frozen picture periodically to improve UX.
> Modern apps should get the area to render and the desired pixel density.
What if you want to smoothly slide an app window over to a second monitor with a different pixel density? That's admittedly a very rare thing, but some people seem to be obsessed with it and insist that it must work. You either have to compose some window surface, or just use clean vector rendering throughout.
Windows doesn't care and neither do I. But still, this can be done in immediate mode if the DE can tell the app it wants it to render the window in multiple rectangles with different pixel densities.
I have a hope for the whole idea, because imo it could significantly improve text rendering in VR by passing or allowing realtime access to the projection matrix along with the areas to render to. Regular VR compositing distorts text and vector graphics due to reprojection.
Plus, as noted above in VRAM speed vs GPU compute speeds, it might actually be faster and more power efficient overall if done right. See e.g. the famous Windows Terminal optimization issue with glyph atlas caching and object reuse.
Across multiple monitors my desktop is 6400x2160, which at 32 bits comes to 55MB.
Considering memory is slow and GPU compute these days is cheap maybe it would make sense to relayout and rerender things each frame directly into screen buffer instead of keeping the window surface buffers resident. That would require rewriting quite a lot of things though.