Hacker News Reader

Agreed, I feel the author even manages to step on their own feet in this manful effort to show malice towards X.

> In contrast to X, Wayland applications always run on the same host as their compositor. Implementations are thus free to optimize for this case

Sweet.. the "go fast" generation is thrilled. We're optimized for a single popular commercialized case!

> Transferring data via shared memory is good enough for software rendering but, for high-performance hardware rendering, it is insufficient.

Whoops.. we're no longer optimal.

> To avoid that penalty, the graphics buffer has to remain in graphics memory. Wayland provides a protocol extension to share buffer objects via a Linux dma-buf, which represents a memory buffer that is shareable among hardware devices

Which, X also has. So, we've gone completely full circle, and we're less capable for it. I'm hopeful for the era of "move a little slower and try to fix a few things along the way."

> Sweet.. the "go fast" generation is thrilled. We're optimized for a single popular commercialized case!

Yes, you should optimize for the 99% case. That is basic software engineering.

> Whoops.. we're no longer optimal.

I don't know what this means. X toolkits since GTK in 1998 have been drawing bitmaps to shared memory. The basic X 2D vector graphics primitives haven't been commonly used for, like, upwards of 20 years.

> Which, X also has. So, we've gone completely full circle, and we're less capable for it.

X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do.

> Yes, you should optimize for the 99% case. That is basic software engineering.

Without considering /why/ it's the 99% case? Even so, just turn this around, top tier games and "tear free" experiences on linux are the 1% case. Why should we rip up the whole graphics stack to chase a "year of linux on the desktop" that's probably never going to materialize?

> I don't know what this means.

I might have failed to follow that thread from the original post, but the author implies this is an issue with Wayland, not X. Then points out that a simple extension covers it, which ironically means, implementations are _not_ free to optimize for any particular case.

> X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do.

Would that be "implicit sync" or "explicit sync?" Anyways, I'm not trying to show malice to any one project or the other or even express favoritism to one or the other, just trying to show that the authors criticism of X is far too strenuous to be useful and seems to be based in a particular and peculiar modern mindset.

> Yes, you should optimize for the 99% case. That is basic software engineering.

Wayland is optimized for car entertainment systems and digital signage. Is this your 99% case?

> X toolkits since GTK in 1998 have been drawing bitmaps to shared memory.

Not true. E.g. several Gtk2.x rendering backends utilized XRender to draw Buttons with gradients without a single bitmap in shared memory.

> X doesn't have the synchronization features that necessitated Wayland. It's simply not the case that X can do everything that Wayland can do.

The X11 extension "Present" does exactly the same as Wayland concerning "synchronization features". What exactly can Wayland do that X11 can't do?

> unsubstantiated claims

Indeed:

> It used to be easy to have any kind of X client connect to a remote X server. Back in the early 1990s on the HP Apollo workstations in college, it was a simple matter of setting the DISPLAY environment variable, but that was before network security was a concern.

Remote controlling an HP 1670G logic analyzer with a Linux PC X server

https://tomverbeure.github.io/2023/12/26/Controlling-an-HP-1...

10 hours ago here on HN: https://news.ycombinator.com/item?id=38778807

and also:

> I recently scored a Hewlett Packard 1670A Deep Memory Logic Analyzer and I finally had a chance to fire it up. This unit dates back to 1992 and is packed with all sorts of interesting options for connecting peripherals to it. One particular feature that caught my eye was the option to connect to an X Server.

A Testament to X11 Backwards Compatibility

http://www.theresistornetwork.com/2013/12/a-testament-to-x11...

10 years ago on HN: https://news.ycombinator.com/item?id=6850591

Yeah, I run Linux VM in background and Xserver on my Windows to work on it. It works very well. The problem is bloated browsers like Firefox where it lags terribly over X.

  gfx.webrender.force-disabled = true

Was helping for a while...

> "bloat" despite being capable of running on a 486

The worst bloat is structural and involves network round-trips, usleep(10000) calls, etc that can't be removed due to expectations that have thoroughly baked themselves into an ecosystem. No amount of Moore's law can make usleep(10000) faster.

I don't know if that applies to X, but I have vivid memories of learning how to tunnel X sessions only to find that VLC was faster and more responsive while using less bandwidth on extremely simple UIs. Something in that protocol had become so shamefully suboptimal that it lost a box drawing contest to pixel pushing, and I tend to suspect there is more where that came from.

You mean VNC?

> It starts with unsubstantiated claims that X suffers from "bloat" despite being capable of running on a 486 and dismissing the fact that the average Wayland compositor + necessary infrastructure is much more "bloated" than X ever was.

"Bloat" doesn't mean "slow" or "memory-hungry". What "bloat" refers to is all the server-side windowing stuff that's no longer used by anything but Xaw or Motif, as well as extensions such as XRENDER that are useless nowadays. X servers carry around all of this legacy baggage that essentially goes entirely unused.

> It fails to distinguish between compositing and hardware accelerated blit operations that allow X to display multiple windows without the need for a compositor.

Compositing has been non-optional in every major desktop OS since 2006 except X. There's no point in supporting a non-compositing mode anymore, as it results in unavoidable tearing. 17 years is a long enough timespan to drop obsolete technologies.

> It talks about hardware planes but fails to mention that no Wayland compositor so far is capable of using them whereas X is using them for the mouse for a long time (which avoids mouse stuttering on high GPU/CPU load).

Huh? Weston has been using them since 2013 [1].

[1]: https://www.phoronix.com/news/MTI5NTE

Throwing out X11 because some features of it are legacy is and always was the entire point. And I don't think it's justified or good engineering practice.

According to my recollection, it was more that the codebase became difficult and unpleasant to work on to the point that it was becoming unmaintainable. And nobody was interested in cleaning it up because that was just not interesting work

That's true, it was a bit of both. But in my experience "codebase became difficult and unpleasant" usually just means that the codebase is large and complex, and people don't want to take the time to understand it. It's always funny to me that people will talk about how elegant a codebase is one day, and the very next decide that it's crufty and old. Did it flip overnight? Did the cruft build up while they were calling it elegant? No, the only thing that changed was the complexity level. When people say cruft, I usually assume they're just frustrated by necessary complexity.

> Mostly because Wayland caused a huge amount of uncertainty and fragmentation

The most divisive thing were CSD (client side decorations). That is mostly a solved issue now (options like libdecor to deal with Gnome and etc.), though an annoying one. What other fragmentation was there?

The article was pretty on point in general anyway.

> What other fragmentation was there?

No strong reference implementation. No protocol for access control and resource sharing. No centralized font rendering (which is a mistake. every app looks different now even when using the same library). No centralized drawing (which pushes things like multi dpi monitors + fractional scaling down to clients). And many other things. Essentially everything a typical application needs except pushing some pixels.

No centralized XYZ isn't necessarily a bad thing and I don't think replicating X being everything and your sink with the same kind of design is a good idea either. But having a common way to do it (libinput, pipewire and etc.) surely helps to reduce fragmentation.

With "centralized" i really meant standardized. X11 has a standardized API that tells you how to implement window managers. Window managers themselves can be swapped, even at runtime without the need for swapping the whole display server or gui toolkit and are as such "decentralized". Similarly there should be a standardized interface to render fonts which every application can/should use and where the actual rendering backend can be swapped (ideally at runtime as well) because a lot of people have a vastly different opinion about how to render fonts (which comes down to taste in the end) but they want all their applications look the same.

The problem is that Wayland predates DX12, Vulkan, and Metal.

The graphics card vendors have converged to a standard. Wayland isn't compatible with that standard. No one on Wayland is willing to throw it out and rearchitect to the new standard.

Huh? Wayland is a surface compositing protocol. It's like DWM/DXGI, not like DX12; like EGL (sorta), not Vulkan; and like Core Animation and the private windowing API in Core Graphics, not like Metal. Different layer of the stack entirely.

I think the above comment refers to common Wayland compositor design using implicit synchronization that's aligned with ideas of OpenGL / EGL. It doesn't have to be an inherent part of Wayland world, but it de-facto became one. Explicit synchronization being an idea from Vulkan / WSI requires a lot effort to be plumbed through all layers.

There was a good post about it: https://www.collabora.com/news-and-blog/blog/2022/06/09/brid...

It doesn't mean what Wayland somehow is incompatible with such ideas, but there is clearly a lot of work to do for them to become fully applicable.

Thanks for that article. It is a good post.