Question about the future of Xorg

[Vladimir Dergachev]

On Thu, 12 Jun 2025, Carsten Haitzler wrote:

> On Thu, 12 Jun 2025 09:44:25 -0400 (EDT) Vladimir Dergachev
> <volodya at mindspring.com> said:
>
>>
>> I see.
>>
>> Hmm.. But then every window has a huge overhead, even when it obscured. Do
>> you know if anyone run scalability tests? What happens if I have 1000
>> windows?
>
> yes. welcome to a composited world! every window consumes at least 1 buffer.
> (width x height x depth). likely 2, maybe 3. there are things you can do.
>
> 1. if app stops updating .. trim down to 1 buffer only - thro waway your
> backbuffer and spare buffer.
> 2. for windows that are minimized the compositor could make a scaled down copy
> of the buffer e.g. at 1/2 or 1/4 resolution and keep it frozen. it consumes
> less memory and is "visible" and usable but low res. the client would have to
> participate but the full res buffer could be released at this point until the
> app has to update/render again. this is currently not a "thing" in wayland but
> one of the areas to explore
> 3. this is the SAME problem in x with compositing so nothing new. x hasn't
> completely fallen apart so wayland won't either. this also  is the case for
> apple and windows too - they have to do the same thing. to do compositing you
> need buffers for every window. you can as above work on minimizing memory use
> but it's not free.

I am using KDE right now, and the kwin compositor has 3 choices for "keep 
window thumbnails":  "Never", "Only for shown windows" and "Always". And, 
of course, I can switch compositor off with Alt-Shift-F12.

I tried setting "Always" and the system bogs down completely. So I usually 
have it with "Only for shown windows". Once every few weeks I am doing 
something particularly demanding of it and I just switch the compositor 
off.

The only thing I lose is the "present windows" effect, but instead I just 
get a list of window titles which is perfectly fine.

So I am hoping other people use Wayland to get things done, and resource 
requirements are not as dire as you describe - otherwise it would be a 
complete no-go for me.

I do get that its more fun writing compositors with Wayland, and I am 
looking forward to seeing what Enlightenment can do, but suspect
most people don't spend all day switching windows.

I hope it will not end up like Android where Google decided that the best 
way to improve usability and security is to prevent people from using 
Android devices in the first place.

>
>>> if privacy/security is a factor, then it's the compositor's job to enforce
>>> that here. apps in general have no access to any other client's windows in a
>>> wayland world (unlike x). the only leaks are via a compositor and the leak
>>> there is pretty much screenshots (pipewire if implemented - that's dbus) or
>>> the new wl screenshot protocol. the compositor can put in this anything it
>>> likes as above. it's the compositor's job then to enforce privacy/security
>>> by blanking/blurring/hiding content.
>>
>> I did not appreciate it was that different. Probably will try to stick
>> with X though a couple of Wayland Kubuntu releases. Unless I get some
>> spare time to fix things.
>>
>> Did anyone try porting Neko? Or does it have to be implemented as part of
>> a compositor?
>
> these things can no longer be implemented as arbitrary clients. clients have
> zero knowledge of other windows in wayland - they don't see them or know
> anything about them. wayland clients are isolated to only knowing their own
> windows. they also can't absolute position windows. they can RELATIVE position
> one window relative to one of your own windows - that's it. absolute
> positioning in xdg shell is not allowed. this is a GOOD thing. so so so much
> abuse removed.
>
> so yes - as a result xsnow, xpenguins, neko etc. no longer can exist as apps.
> they would be something compositor private only - if that compositor allows.
> e.g. vie plugins/extensions etc. this is a good thing. this definitely improves
> security/privacy.

But that also means you cannot implement assistive apps like "Xmag", and 
how would Zoom-like apps work?

>>
>> Yeah, I see it now. I suspect at some point people will try plugin
>> architecture for wayland compositors, because many interesting things can
>> only be done by being within one. Or, make a new protocol that allows
>> plugins to be separate processes.
>
> a common plugin arch won't happen. i can pretty much bet you that. but... what
> you may eventually see is a common agreement on what wl compositors SHOULD
> support and do to be functional and useful to people and what is really so
> super niche that there is no value in the effort to write and maintain such
> code for those features.
>
> this is why you can have many wayland compositors. they can compete and address
> different userbases and "markets". :)

Except that the compositor would need to implement toys like Neko, tools 
like xmag/kmag, and teleconferencing client as well.

And where before you can run KDE, but also use some Gnome apps and plain X 
apps, now you got to choose - one compositor has better teleconferencing 
and the other has better magnification, and another better effects and so 
on.

(PS xmag/kmag are really useful if you are looking at 32" 4K monitor via 
VNC from 15" laptop. All the fonts are tiny)

>
>> Also, before I only had to worry whether Xorg has drivers for my video
>> card, but now it is the question of whether kwin or enlightenment has it.
>
> well they will all use kms and things like mesa and libinput - so you don't
> need to care there. the drivers are essentially in the kernel or abstracted by
> mesa (opengl, vulkan etc.). so realistically quite a lot has, over time, been
> abstracted.
>
> now one area that has NOT been is... 2d accelerators. this has for pretty much
> ever been a no-mans land of "no library exists to abstract this" like mesa does
> for 3d. in the end most accel has since just ended up punted to the 3d unit.
>
> for 2d rendering accel - it's black magic still and tbh i don't think anyone is
> bothering. the only other area is in kms hw plane handling and doing this in
> optimal ways. kms abstracts this so it can be done - but different compositors
> may do different things.

Well, the 2d library does exist and it is called X11. You also have higher 
level Qt and gtk, and even Tcl/Tk :)

Speaking of which, it would be fun to see what happens if one implements 
compositor with Tcl/Tk. If only I had more spare time..

best

Vladimir Dergachev