> 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."
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.
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.
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?
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
gfx.webrender.force-disabled = true
"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].
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.
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.
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.
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.
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.
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.
It fails to distinguish between compositing and hardware accelerated blit operations that allow X to display multiple windows without the need for a compositor.
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).
It proclaims that certain protocols are "commonly used" when they are really in a experimental phase or actually not commonly used.
I get it. Linux userland graphics is huge a mess right now. Mostly because Wayland caused a huge amount of uncertainty and fragmentation. At least call it out as such and don't pretend otherwise.