Sebastian Krzyszkowiak @dos@librem.one

@datenwolf @newbyte @mirabilos @jzb Modern display engines provide some in-hardware composition abilities. You're explicitly not interested in window composition, fine, but applications want to draw over buffers that are opaque to them, such as video content, which can then go straight from the VPU to the display engine without CPU or GPU involvement.

That's well-supported today with Wayland and necessary for reasonable performance on some hardware out there.

@datenwolf @newbyte @mirabilos @jzb Well, maybe because the compressed buffer is produced by the GPU and the display engine knows how to decompress it on the fly while it's fully opaque to the CPU?

@datenwolf @newbyte @mirabilos @jzb So how are you going to offload surfaces to hardware planes while preserving the ability to save memory from unused portions of the window? How are you going to utilize display's engine framebuffer compression to hit bandwidth targets on high res screens?

X11 can do lots of things, but only once you make it move away from these "old-school" ways and explode the complexity.

@datenwolf @newbyte @mirabilos @jzb I have debugged plenty of X11 and Wayland client code in my life and having to deal with "combinatorial explosion" of stuff definitely describes the experience of working with the former more than the latter.

@datenwolf @newbyte @mirabilos @jzb ...and outright don't work when presented with modern challenges, unless you're willing to put the extra effort or compromise on performance as well :)

@datenwolf @newbyte @mirabilos @jzb Buffer passing mechanics are extensible in Wayland. Even dma-bufs are in their own extension, the only one in the core is wl_shm (which, BTW, works by giving the client a buffer to mmap to...).

What's more - some toolkits, such as Qt, even have elaborate plugin support to handle custom buffer passing mechanisms that you could use.

I won't implement this for you as I'm not interested in it, but you can just sit down and do it!

@datenwolf @newbyte @mirabilos @jzb (that said, a non-composited shared-framebuffer system could be easily built on top of Wayland anyway)

@datenwolf @newbyte @mirabilos @jzb Except it's not 1980 anymore. Buffers to be presented on screen come from all sorts of sources - CPUs, GPUs, VPUs, ISPs. Some can render directly to a shared framebuffer, some can't. Some could be cropped to save memory, some can't - and when they can, they'd need to reallocate.

Yes, you can design a system that will consume less resources if you make it special-purposed to the set of requirements you happen to care about. Go ahead. Wayland is not that thing.

@datenwolf @newbyte @mirabilos @jzb Yeah, let's instead have the apps OOM once you drag their windows or view them in an expose-like arrangement 😂

@datenwolf @newbyte @mirabilos @jzb So first it was supposedly about bandwidth (which is not an issue in this case either thanks to damage tracking), but now it's suddenly about RAM usage which you'd need to pay up one way or another anyway if you wanted to implement features commonly expected from desktop environments these days? 🤔

@datenwolf @newbyte @mirabilos @jzb Ah, so you're not anti-Wayland, but anti-composition?

Then you'll be relieved to hear that Wayland is designed in a way that makes composition unnecessary in the case you described :)

@datenwolf @newbyte @mirabilos @jzb Maybe in your world dma-buf passing weights more with higher resolutions, but in the real world when you want high performance you end up with things like Gamescope.

@datenwolf @newbyte @mirabilos @jzb I have used KiCad and created projects in it under Wayland with no troubles whatsoever.

You know that Xwayland exists and isn't going anywhere, right? It's not some temporary glue to ease the migration, it's the main still maintained X11 implementation these days and it's here to stay.

@StefanThinks I remember, but it was of disappointment rather than awe, so I'm fairly certain it couldn't compete 😂

@mntmn It's been there for a few releases already, though it was getting additional improvements over time. It's been snappy on the L5 in the last months. 2.52 has been released today, it's not yet in Debian (though 2.51.93 is in experimental), but should be soon and it looks promising too: https://webkitgtk.org/2026/03/18/webkitgtk-2.52-highlights.html

(it's maintained by the same people as WPE)

@mntmn Recent versions of WebKitGTK with the new dmabuf renderer (which it shares with WPE AFAIUI) perform similarly well. It only needs some papercuts around touch input handling solved - I have recently worked on some, but there's a few more left.

@marmarta What I meant by "aesthetics" would also contain (or perhaps actually be defined by) this desire to streamline, so thanks for putting it into much clearer words than I could 😀

@marmarta Good UX requires validation by testing with actual users achieving their goals, not designers making things appeal to their aesthetic sensibilities (which seems to drive at least some of these anti-power user sentiments). The latter can be helpful too, but since most designers working on FLOSS lack resources needed to do the former it often ends up actually detrimental to UX...