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

[vidarh]

> Once you are talking about double/triple buffering every client

Nobody is talking about double/triple buffering every client, but the final composited surface.

> you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue

Double-buffering was viable and done on quite a lot of 1980's hardware. The point remains that this is not a protocol issue.

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

I didn't suggest it would have been simple. I suggested it would have been simple than a well over decade long effort to write a new system from scratch.

The point being that the reasons for the existence of Wayland are not technical, but political, due to the lack of willingness in the Xorg core team to break compatibility at the time. And we're still paying the price.

[md8z]

You need to double buffer the clients or you will still get flickering and noticeable redraw. You can see this with older X clients. It actually is a protocol issue because X was explicitly designed to do this.

You are presenting this as if it's some kind of decision between "break compatibility" and "start from scratch" when really those are a lot closer than you think. Realistically, most of the X server is still overdue for a major rewrite/refactor. But I really doubt anyone would ever volunteer to do that work at this point.

[vidarh]

No, you don't need to double buffer the clients if the clients are properly designed and flush the request queue cautiously rather than willy-nilly, and the server takes a minimum of care rather than just stupidly processing requests one by one. None of the clients I use give flickering or noticeable redraw.

There may certainly be cases where it'd be harder to avoid, but realistically this hasn't been a problem for most X users for decades. Of course I'm not doubting that it is a problem for some, but it's not for me and haven't been since the 90's.