Comment by mort96
14 hours ago
* I never said all software handles the swapchain itself. The front and back buffers are obviously not usually allocated in user code. But they're allocated nonetheless and contributing to memory usage.
* Not every app is fullscreen, but I was using a maximized app as an example. If you make the window smaller then yeah obviously the numbers get smaller proportionally.
* A ton of people have 4k displays, it's difficult to find a moderately high end laptop without a 4k display these days. In any case, that was the hypothetical example I used.
* If you have a window that's roughly 4k resolution, and you want a background picture which fills the entire window, that's gonna be a roughly 4k resolution pixel buffer (unless you stretch a smaller image, but that looks ugly).
* Depends on the text renderer. I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer. I know that this is the typical recommendation for handling high quality rendering of longer pieces of text with Canvas on the web too. Maybe a typical win32 app actually does render each glyph fresh every frame from a font atlas, I'm not familiar with Windows APIs specifically. I apologise for the inaccuracy if that's the case.
* I'm pretty sure you're wrong here? If DWM has only one buffer which all windows share, how does it handle the case where a partially obscured window goes unresponsive for a bit as the user removes what obscures it? In old school non-composited X11, the answer is that the X server paints in the newly revealed area with grey pixels and asks the window's process to re-render that region, causing a lingering grey region if the app is frozen. Preeeetty sure that Windows 11 doesn't do that. But do you have documentation on this?
>it's difficult to find a moderately high end laptop
Terrible news for you, people work on dogshit dells given by their company and netbooks, not high end laptops. Macbook Pros, high end laptops, etc are exceedingly rare. (And can also deal with the high memory usage by virtue of having more memory).
>you want a background picture which fills the entire window
Which you rarely do, and also you don't develop for either, you're going to have a 1080p image at best, and then a bug report from that one client saying "background is blurry" in your backlog for the next 5 years.
>I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer.
Then you're using it wrong/using the wrong tool. Re-paying text layout at every render is already painful and it should be cached, your font rendering should absolutely be in a texture atlas.
>If DWM has only one buffer which all windows share
Slightly inaccurate in my answer there, but DWM only keeps one final composition buffer, which it handles itself from the various windows (that do have their own buffer, but only for their size and are only kept active if the window is visible.)
Are you disagreeing just to disagree? My numbers are obviously not going to fit every app in every situation, but I think they illustrate a perfectly realistic use case
For the text rendering thing, I think we're talking past each other? Nothing I mentioned implied redoing layout every frame? You render to a pixel buffer, upload that pixel buffer to the GPU, then just draw that texture every render.
For DWM, it sounds like you agree it has one shared composite buffer (which I didn't count in my calculations) and one front buffer and one back buffer per active application. Exactly as I said
In reply to user well_ackshually:
> Are you disagreeing just to disagree?