Re: [dev] Wayland compositors
On Tue, 31 Aug 2021 14:28:29 +0100
Nick <suckless-dev_AT_njw.me.uk> wrote:
Dear Nick,
> Any thoughts, experiences, recommendations?
the discussion has been very fruitful. Let me share my thoughts.
Wayland the protocol is actually rather simple. It's a very thin
messaging layer between a compositor and clients, nothing more.
But this is exactly the problem: It's too thin and the
Wayland-developers didn't dare to go beyond a minimal set of things.
All of the things that are breaking are those based on
(compositor-specific) Wayland-extensions which add functionality you'd
expect (gamma control, screen sharing, etc. etc.). I will never forgive
the Wayland-developers for their lack of courage.
We're talking about the next generation of display/window managers, and
they messed it up so badly! Just a few things that come to mind:
- network transparency is a _good_ thing and was thrown away way too
easily. I like being able to run GUI-applications from time to
time via ssh. Most of the time they are just basic
GUI-framework-programs you could "stream" very efficiently, but if
you're talking about composited surfaces, I would expect Wayland
to do that for me too, via a compressed stream or something.
It's trivial to stream Ful-HD-Video P2P using modern compression
algorithms, why wasn't this taken into consideration?
People are always talking about moving away from the single
computer and into the "orbit" (see Urbit, etc.). Today's
technology makes it possible to be much more flexible in this
regard.
- color management was totally ignored. This could've been a strong
point for Wayland, but instead they made it even worse than in X,
which is actually a difficult feat. We need to move away from the
sRGB-monoculture, especially because it's not bloaty to actually
support proper colour management and it has tangible benefits.
- everything about Wayland is hacky and deeply integrated into
Linux, but what for? To get "perfect frames", as it is often said?
This could've been done so much better, for example by going
vector-first. Most stuff in a GUI can easily be represented by
vector-data, which is very sparse. You do have bitmap-surfaces
from time to time (video player, browser, games, etc.), but it
would've been a very interesting and radical approach. The
advantage of this is that you don't need to think about dpi and
other shit except in those bitmap surfaces. All the rasterization
would be the last step and not intrinsic to the protocol itself,
but just the compositor.
Anyway, to sum it up: Probably nobody here is really a fan of X, but
it's what we have. Wayland is an underwhelming mess and they really
dropped the ball here. The mix of (often incompatible and competing)
extensions that are made up and forced upon us (while leading to more
and more userspace-applications relying on them and unexpectedly
breaking in vanilla Wayland-compositors that don't want to be tainted
with the garden-variety of extensions) is just horrible.
I used to have enthusiasm about Wayland, but now this feeling has
completely been replaced with pity. They really dropped the ball on
this one and I will not waste any more time with it.
With best regards
Laslo
Received on Wed Sep 08 2021 - 20:35:33 CEST
This archive was generated by hypermail 2.3.0
: Wed Sep 08 2021 - 21:36:08 CEST