Re: [dev] Wayland compositors

From: Laslo Hunhold <>
Date: Wed, 8 Sep 2021 20:35:33 +0200

On Tue, 31 Aug 2021 14:28:29 +0100
Nick <> 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
   - 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

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