[Seirdy]

1. Wayland does support remote execution; see waypipe for an example.

2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).

[vidarh]

X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.

[Seirdy]

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing.

Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

[vidarh]

The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's.

You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.

[fredoralive]

I'm not sure if RISC OS had an X11 server, but Acorn did offer an ARM Unix (RISC iX) in the late '80s, and it did have X11.

[Seirdy]

I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.

The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL

[vidarh]

X ran just fine on machines with graphics chips with no acceleration at all, just dumb frame buffers.

You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance characteristics.

As for Vulkan, there's no reason you can't use Vulcan with X. It's again an implementation question, not a protocol issue.

Now, the X protocol is awful, to be clear. There are plenty of issues with X that were worth fixing. But the time it has taken to get Wayland to a usable state (many would argue it still isn't - I certainly have no interest in running Wayland other than with XWayland possibly given the current state) suggests that opting to start from scratch instead of upgrading X step by step was a relatively poor choice - the X protocol is easily upgradable.

[md8z]

X ran "fine" on those machines if you were ok with all the problems of 80s-90s era graphics such as flickering, tearing, windows taking noticeable time to be redrawn, stale contents when resizing or when something else moves above them, the occasional "solitaire effect" where the back buffer doesn't get cleared, or any of that other fun stuff from dealing with expose events...

Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.

[qwerty456127]

> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for

Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio?

> I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.

Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.

> The difference will widen as Vulkan

I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that

[Seirdy]

> Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.

A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more.

I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link.

A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.

[pantalaimon]

There are no problems with running Vulkan applications on X11.

You must confuse something here - wlroots recently got a Vulkan backend, meaning you can run it on top of Vulkan API.

It has nothing to do with what Graphics API the clients will use.

[Seirdy]

I was referring to the fact that OpenGL is becoming a second class citizen among the silicon giants, with more attention being drawn to Vulcan/Metal/etc. Now that sway supports a Vulcan backend, it won't be left in the dust stuck on OpenGL.

I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.

[qwerty456127]

What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO.

I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.

[Seirdy]

If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.

The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.

[qwerty456127]

> If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.

I see. Curious that I have never noticed anything like this though. I have always been disabling compositors as I realized I don't really care if my panel is transparent. Perhaps the problem just doesn't affect Intel graphics (Raspberry Pi browsing is slow anyway so fast scrolling just doesn't exist there).

UPDATE: I've just realized I've actually seen screen tearing many times - always within specific Windows apps ran with Wine, e.g. Total Commander.

[vidarh]

Screen tearing is largely a software issue anyway - the moment you have hardware capable of double buffering there's no excuse for it unless you don't have sufficient memory.

[kaba0]

Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.

[vidarh]

There's nothing stopping an X server implementation from doing compositing natively.

[kaba0]

Other than writing an X server implementation is akin to writing a web browser from scratch?

[DonHopkins]

Mid 80s hardware, actually.

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:

https://blog.dshr.org/2018/05/recreational-bugs.html

>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");

WHAT IS YOUR ROOT?

    root = RootWindow(display, DefaultScreen(display));

AND WHAT IS YOUR WINDOW?

    win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
                              BlackPixel(
                                  display,
                                  DefaultScreen(display)),
                              WhitePixel(
                                  display,
                                  DefaultScreen(display)));

OH ALL RIGHT, YOU CAN GO ON.

(the next client tries to connect to the server)

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");

WHAT IS YOUR COLORMAP?

    cmap = DefaultColormap(display, DefaultScreen(display));

AND WHAT IS YOUR FAVORITE COLOR?

    favorite_color = 0; /* Black. */
    /* Whoops! No, I mean: */
    favorite_color = BlackPixel(display, DefaultScreen(display));
    /* AAAYYYYEEEEE!! */

(client dumps core & falls into the chasm)

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");

WHAT IS YOUR VISUAL?

    struct XVisualInfo vinfo;
    if (XMatchVisualInfo(display, DefaultScreen(display),
                         8, PseudoColor, &vinfo) != 0)
        visual = vinfo.visual;

AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?

    /* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */

WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!!

(server dumps core & falls into the chasm)

[vidarh]

> Mid 80s hardware, actually.

I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)

> WHAT IS YOUR ROOT?

A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.

The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.

So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.

There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.

In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.

EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.

[DonHopkins]

The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib.

I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.

https://www.cliki.net/clx

Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.

So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.

At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?

Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.

But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.

That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.

[yjftsjthsd-h]

> That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries

Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.

[md8z]

No, you have it mixed up. Wlroots is on the server, the Xlib problem is explicitly with client libraries.

[vidarh]

Absolutely agree that a general purpose replacement for Xlib would be a massive pain, but providing sufficient support for the core protocol to let you add whichever request types you need is quite simple (and I lifted that from a decade old starting point and made it work).

And for my use I only need to support about a dozen requests types, and no third party libs, so it's not that bad. My starting point only linked with Xlib anyway, nothing else, and I verified which requests Xlib actually sent via xtruss before I started.

But of course, that's because I only want to actually use it for something very simple. If I wanted to do something more complex I'd wrap a higher level library instead.

[sprash]

You think this is bad? Just look at a native Wayland "Hello World" client [1]. This doesn't even print hello world. You have to do the text rendering yourself. And you need at least 500 more lines to implement the equivalent to a simple XGetImage() call.

1.: https://github.com/emersion/hello-wayland/blob/master/main.c

[bitwize]

Your toolkit should abstract all that away. We have these wonderful things called dynamic libraries, that X was designed for a world without because they didn't exist under Unix yet.

[sprash]

If toolkits can "abstract that away" they can do the same on X11 and there is even less reason for Wayland to exist. There is no reason for you to even care about X11/Wayland if you only work with toolkits. So stop participating in a discussion that doesn't concern you.

[md8z]

"they can do the same on X11 and there is even less reason for Wayland to exist."

Well actually it's the reverse: the more abstractions were put into toolkits, the more it became obvious that there was little reason to use everything in X11.

[erik_seaberg]

Waypipe ships client-rendered images across the network; datacenters would fall back to software rendering because there’s no way to take advantage of a user’s desktop GPU. I think the industry will continue moving to Javascript or Wasm apps as the most widely portable and accelerated remote display system we have.

[andrewshadura]

> Waypipe ships client-rendered images across the network

That's also exactly what most modern GUI toolkits do when they run on X11.

[WalterGR]

Sorry if I'm being obtuse, but... why would X11 toolkits need to ship client-rendered images across the network?

Doesn't the server tell the client what to render, and the rendering happens on the client? Why would that result then be shipped over the network?

https://en.wikipedia.org/wiki/X_Window_System

[andrewshadura]

Also, in X terminology, the server owns/controls the display, the client is the app that wants to draw a window on the server’s display. The classic architecture would be client telling server what to draw, but these days what really happens is that clients draw locally into a buffer and then tell X server to draw the contents of the buffer.

[andrewshadura]

That’s been tried, but most toolkits stopped doing that because it was unreliable, slow, and the number of primitives offered by X wasn’t sufficient for any modern GUI.