[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.

[vidarh]

Avoiding flickering and tearing is something we've known how to do since the early 80's. It's not a protocol issue, but an implementation issue. If you don't double-buffer and and/or sync updates, then sure.

Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help you with that. Blitting the graphics onto the screen was back to being limited by the hardware from MIT-SHM arrived ~'91.

> 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.

Upgrading the core protocol has hardly been tried. What has been done is piling on extensions - ironically exactly the same mess happening with Wayland to try to get back to reasonable parity with X. But even most of those didn't go very far. E.g. none of them tried stripping out more than a tiny subset of legacy stuff.

The very first message an X client sends includes the protocol version. Nothing stops you from starting by bumping the major protocol to 12, removing whatever you like from the protocol if a client connects and asks for 12, and upgrade Xlib to ask for 12 first and try again with 11 if the server barfs. Nothing stops you from making a version of a server that just refuses to let clients asking for 11 to connect, and defer those to requiring a proxy to translate/implement whatever you strip out if you care rather than upgrade the clients.

I understand why people got fed up and did Wayland instead, but that was largely organisational, not technical.

If there had been the will they could have done a dozen iterations of the core X protocol in the time it has taken to get Wayland reasonably usable and removed things piece by piece instead. To take a concrete example, there are about half a dozen ways of rendering text in X. Nothing would have prevented saying that X12.0 has XRender by default so you don't need to query for it, and that no other text-like rendering operation than RenderCompositeGlyphs8/16/32 is supported and just yanking all of the font code out of the server. If anyone cared, taking the old code and implementing a client side library providing the old string drawing functions would keep compatibility easily enough.

Nobody seriously tried doing this, because the politics of it was maintaining full backwards compatibility or building something new.

Wayland was a technical solution to a political problem. Frankly a fork and iterating would have likely gotten buy-in much faster.

[md8z]

Once you are talking about double/triple buffering every client, you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue. Of course Wayland doesn't "solve" it but it does remove the old slow code paths. If you're on an SoC with a GPU then you want to use it as much as you can otherwise you are wasting CPU.

The rest of your comment doesn't really make any sense to me. Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not. There is zero will to actually do that, I've heard similar suggestions to make X12 for the last 15-20 years, and nobody has ever cared enough to do it because the only reason anyone ever uses X is for compatibility with old software. Once you take that away, there's nothing left. The closest existing thing to an X12 is, well you guessed it, Wayland.

[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.

[vidarh]

> 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.

i3/dwm (or any X window manager), unlike Sway (or any Wayland compositor) has nothing to do with client window contents rendering. X and Wayland works fundamentally differently in that respect. Under Wayland the compositor and wm is the same. Under X the server and wm are separate programs in separate processes, and the latter is not involved in rendering the client window contents, only the window chrome, if any.

[qwerty456127]

I see. Quite a reasonable, detailed explanation, thank you. I didn't notice any visible difference in perceived performance (just using the PC to write code, browse the web and watch videos) when I switched spectre/meltdown mitigations on/off on my old Core 2 Duo PC though. It just always worked perfectly fast.

Meanwhile, I often don't need any network connection (when coding, watching pre-download videos, or running data/number-crunching or build scripts). Can I expect 90s-like efficiency if I disable all the mitigations and hardening stuff?

[Seirdy]

There are...a lot of good reasons to keep the mitigations enabled. All nontrivial software has bugs, and hardening measures can keep some of the worst ones in check. Frankly, the Linux desktop needs more of this, not less.

That being said, one writeup explained how disabling several mitigations improved http server perf by several factors: https://talawah.io/blog/extreme-http-performance-tuning-one-...

[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.

[vidarh]

X WMs do not have anything to do with rendering. The conflation of the server/compositor with the window management is a Wayland thing, and one of the big regressions in flexibility that current Wayland compositors bring. You may be confusing X WMs with the X server or with the toolkits rendering backends.

[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?

[vidarh]

There's absolutely no reason to write an X server from scratch to add native compositing support.

You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.

[qwerty456127]

> You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done.

If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.