On Thu, 12 Jun 2025, Carsten Haitzler wrote:
On Thu, 12 Jun 2025 09:44:25 -0400 (EDT) Vladimir Dergachev
<[email protected]> 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
