Question about the future of Xorg

Fri Jun 13 18:46:35 UTC 2025

On Fri, 13 Jun 2025 11:41:54 -0400 (EDT) Vladimir Dergachev
<volodya at mindspring.com> said:

> 
> 
> 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.

this is in x11?

> 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.

wth do you run and do to be that bad. i have NEVER seen anything like this...
not on my laptops with integrated gpu's... not on my desktop with discrete...

maybe it's a kde problem/thing? like i can have 50+ windows with zero issue.
currently have 27 and nothing is bothered at all. admittedly that's windows
spread across multiple virtual desktops... but i know i do NOT make any effort
to "undirect" windows to remove buffers for windows on other desktops. i do
know that they are completely nuked from the compositing scene graph and get no
render or even context change effort as the scene graph skips them... but the
buffers exist and use video ram. in today's world that is not that much...
unless you really e beginning to run very low on video ram or "regular ram" for
integrated gpu's - i don't see why this matters?

what's your working style? put 50+ windows on a single desktop and "alt+tab"
between them? 

i just opened 30 terminals and maximized them on the same desktop... i can
alt-tab between them without anything bogging down. i can open a 31st small
terminal on top of these 30 and drag it about smoothly. my gpu is a 6800xt - so
a good gpu but from like 5 years ago. it's not some top of the line thing.

all my terminals are the usual solid (not transparent type) so technically a
good renderer will actually skip and avoid rendering all but the top most
maximized window... maybe this is kde's problem?

so either your workflow is something i'm not reproducing, you have one hell of
a potato of a gpu or cpu, or ... this is a kde thing?

> 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.

they are the same really as a composited x11. no real difference at all.

> 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.

hahahah! :)

> 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.

that i do not think will be the case.  :)

> >>> 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?

they can;'t be implemented as standard separate wayland apps. they have to be
tightly bound to the compositor. so it's either a compositor feature built-in,
or some extension/tool/plugin for your compositor... well if you think of a
tool like a live magnifier around the mouse cursor wherever it goes...

if its a 1-off "screenshot then display a copy of it and just scale that up"
then there are wayland protocols for that - but the idea is that screenshotting
protocol access will be limited and a compositor may do a very android/ios
thing of ask you to grant permission first.

> >> 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.

well some like neko etc. -= yes. per compositor. accessibilty features would
also be "per compositor" and i'd lump xmag in that. teleconferencing (zoom
etc.) will be as ai described - limited access "screenshot" protocol -
pipewire offers this. there's another wl protocol based one (imho better/right
thing to do).

> 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.

well see above. but for a bunch of things - yes. so one may have neko and
another allow for nice accessibility.

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

i know.. tho you should just bump your fonts up .. though wayland can scale
much better than x could due to being bale to individually scale different
client windows and they don't need to know (because they don't get absolute
positions - thus a compositor can invisibly transform not just the output but
also input coordinates to any window). so by design andf adding such limits to
what clients can see or do (and thus it limits xneko/xsnow etc.) it allows the
solution of real problems like dealing with many screens of varying dpi and
different apps of varying scaling ability to transparently scale that client
up and down to make them look right/good etc.

> >> 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 :)

well tbh the 2d rendering in x11 is likely now backing through glamor which
uses the 3d unit... :) likely... depends. :) but there has been no lower level
api/abstraction "direct to device" beyond mesa + drm.

> 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..

in theory you could - assuming they had access to all the libraries and
api's. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com