Re: [9front] Thoughts on Wayland?

[Shawn Rutledge <lists@ecloud.org>]

On Mon, Aug 05, 2024 at 10:02:10AM +0200, hiro wrote:
> > In that respect, it's strictly a worse fit for Plan 9 than X, which at
> > least is designed with networking in mind, I suspect?
> 
> Both Plan 9 and X are designed with networking in mind.
> 
> > Though, there is a tool for networking transparency on Linux with
> > Wayland, so it's not impossible.
> 
> I bet they are multiplexing all graphical output as a lossy video stream.
> Careful design from the ground up on the remote protocol level is
> needed to solve the problem in a lossless, bandwidth-efficient, and
> roundtrip-reducing way. And then all applications using the protocol
> have to use it in the right way and not try to sabotage all the
> efforts that got put into this mechanism: modern x11 programs suffer
> from the same problem that wayland does, kde/gnome/google/mozilla et
> all started to use x11 inefficiently, introducing bad
> round-trip-sensitive implementations for unimportant cosmetic features
> like animations.

Yes that's an old problem. One place where I worked over 20 years ago,
the boss had set up dual networks: one for internal stuff and one for the
Internet. He had a pile of surplus NCD X-terminals, which he made us use
for Internet stuff, running the actual programs on a shared Sun machine: so
fully remote over 100mbit ethernet. (Of course he was also routinely spying
on us to make sure we didn't waste too much time web-surfing or
socializing.) It quickly became clear which programs were efficient that
way and which weren't. Qt and GTK were both already trying to render the
whole UI into one window, doing widget compositing themselves; I think this
explanation here is from that time period (and offers workarounds):
https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-widgets
That just made them feel much slower under such conditions, because often
the buffer for the whole window had to be resent. (VNC works better than
that, because of tiling.) But the tradeoff is if each widget generates
resources on the X11 server side (which in this case had a rather small
amount of memory, a few megabytes), there is a limit to how complex the UI
can be (so you are stuck either way; even using too many colors was
expensive on those terminals). And the window-per-widget architecture is
slower in the more common case where the X server is on the same machine
where the application runs, shared memory is possible, and you might even
have a GPU.  Don't trust the X server to be the quickest way to render your
2D stuff: do it on your own if you want to be sure that it's as quick as it
needs to be. Plus, AA really benefits everyone, and
https://en.wikipedia.org/wiki/X_Rendering_Extension is only for fonts, not
for arbitrary graphics. (Same problem as on Plan 9. Should we blame Keith
Packard for not going further than just font rendering?) There's no way to
have AA in arbitrary 2D graphics rendered on the X server, AFAIK. So
basically the widget toolkits gave up on supporting efficient networked X11
ages ago, and not for completely frivolous reasons. There were only a few
users, maybe not vocal enough. Not sure what's the state-of-the-art toolkit
that is actually good at it, though. TK was ok, as I remember.

(The work itself at that company was interesting: on the upside, where else
could I have been paid to write Scheme full-time for a year? I still use
Scheme now because of what I learned there. And I was working on remote-UI
stuff there too. But got fed up with the low pay and control-freak
attitude, and left as soon as I got a better offer.)

Anyway the toolkits got away with that on X11, which maybe contributed to
the assumption that shared memory is fine for Wayland as well, and
remote-desktop use cases are a niche case that can be served with things
like VNC, RDP, and video streaming. The KDE/Plasma project is pursuing all
of these, by the way. There's pipewire.org which I got the impression was
for audio first, and then got video shoehorned in as well. Accordingly
there's https://invent.kde.org/plasma/kpipewire ...not that I've tried it.
And https://conf.kde.org/event/5/contributions/133/ ... that one surprised
me, because I thought RDP is a complex Microsoft beast. Seems like a lot of
work to support that in open source.

But if video streaming is the solution, it seems to me an assumption is
being made that the server (where the applications run) has a GPU then: it
would help for rendering the applications (with AA, blending, animations
and all), and it would help for video compression too. Somewhat of a break
from tradition then. I agree that a solution designed specifically with low
bandwidth and low latency in mind ought to be better. But is 9p really for
that? I'm trying to work that way; time will tell...