> Was Wayland not architected to fix latency issues?
It was designed to fix tearing issues, not latency issues.
But then the Wayland designers found out that players often prefer tearing to minimize latency, so the tearing protocol was implemented.
When a committee of perfectionists, rather than real people or companies, design something, you often get something that is completely unusable by anyone but that committee.
And that's exactly how it's played out so far. Wayland is still largely incomplete, not to mention it doesn't even have a reference implementation [1], and still doesn't include/describe several essential desktop APIs and features, which results in this protocol not having a ton of universal tools and applications that work across all of its implementations, including but not limited to:
* Keyboard layout switching and input management
* Display configuration
* Clipboard management
* Tools to manage windows/automate tasks
* Lots more
It's a damn ugly mess that has led to a lot of fragmentation with no obvious benefit. Currently, only KDE and Gnome have somewhat usable Wayland implementations. If you use anything else? You're SoL.
It's almost like you don't want tearing when browsing the web and your documents, but games can take over the precise control of rendering.. because they are games that want to do so?
The numbers presented in the article (~1 additional frame of latency on Wayland) are from someone using GNOME with the Mutter compositor. This means that neither the X11 or Wayland session has screen tearing. I imagine the X11 input latency numbers would go down by around half a frame on average if the author was using a different window manager without a compositor.
Of the things you list, IMO, maybe the display configuration should be part of the Wayland protocol.
It might be a better technical design to have the other stuff outside of the display protocol. Just because Xorg implemented something does not mean you have to put it in the Wayland protocol.
Routing of input events to windows has turned out to also be extremely important for a display subsystem in practice. It wasn’t just X11 that did this, it was also the NeXT window server, and Sun’s NeWS, and SGI’s pre-X window system, and the original VAXstation window system on VMS, as well as how both modern macOS and modern iOS and iOS-derived platforms work.
In any of these cases there may be one or more daemons behind the scenes handling the “raw” input—possibly even in cooperation with kernel-level pre-processing code, to ensure low latencey—but most event delivery to applications is associated with windows, with options to get lower-level access if needed.
One of the things that helps many of the systems described above with latency is kernel participation, whether by pushing much of the preprocessing of events down to the drivers so there’s little for userspace to do, or by implementing kernel-level zero-copy IPC (e.g. use of Mach messages by NeXT and Apple).
If human interface IPC happens entirely in userspace and requires multiple context switches to get an event from device to a display change, you’ll wind up with hitches and delays unless there’s some sort of scheduler hinting that ensures each stage in the pipeline runs immediately after the last.
This is, of course, why there was a lot of desire by Wayland advocates for kernel dbus support, but they went at the problem backwards: “Let’s take DBus, and make it fast by putting it in-kernel,” *without* first trying to make it as fast as possible without kernel support, *and* without trying to figure out the minimal feature set for kernel-level IPC that would be needed to support it (which may not look like DBus).
As I understand it, the tearing thing (no vsync) was only implemented after Valve pleaded, begged, and sacrificed a small animal to the Wayland developers.
Wayland is just a protocol that is probably implemented over and over and each implementation might have issues. It's mostly likely the different implementations having issues.
Was Wayland not architected to be simpler to implement than the (antique) X11 protocol?
Not arguing though, you are right it is just issues: Drivers, the Wayland implementations, how some plethora of apps and libraries have been battle tested then optimized, years over years, for X11. Not as much for Wayland display yet.
Wayland is simpler because it does less. And among the things Wayland doesn't do and X does are things that people need. It means these things have to be implemented elsewhere.
It is a common problem with these "simple" things. The problem is complex, and if you simplify one part, you are just pushing complexity elsewhere, you are not making it disappear. It is sometimes a good thing, but in the case of Wayland, it didn't go well.
There is also the option to make complexity disappear by just convincing people that they should not want to do what they want to do. This was the kind of response to what I needed to do. Then I had to switch back to x11.
In any case wayland is not bad if you only have pretty basic needs I guess, some basic things look easier to me there from a user perspective, and troubleshooting x11-related issues for a non-technical person is no fun either.
> Was Wayland not architected to be simpler to implement than the (antique) X11 protocol?
I think it's safe to assume that it is actually simpler, given that we already have multiple Wayland implementations, but still basically just the one X11 server implementation. Can one or more of those implementations shave off one or two milliseconds overs the next 40 years... Probably yes.
Sure, on linux all you really have is xorg, what used to be xfree86, but I have used xsgi, and there are X servers for windows, heck, I have even seen this amazing demo Xserver that ran on the web.
footnote: there is something wrong with the commonly used web search engines and I am unable to find that X11 web demo, I think they are prioritizing recent content over good content. you would think with how interesting that web demo was it was it would show up right away. but I got nothing, so no links. Anyway it was a deep dive into the intricacies of X11 window painting and the author had ported a limited subset of an X server to javascript in order to provide a live demonstration of the topic. I will keep looking.
Architecture contributes, but all it takes to blow input latency is some inefficient code almost anywhere in the input or rendering pipeline. The Apple IIe didn’t really have very many layers between the keyboard and the CRT. Wayland might have an optimal architecture in theory for latency — I don’t know — and latency could still be ruined by not fully optimizing the other components in the stack.
Gnome was fixed a few years ago to remove significant latency it was adding. May have been a factor if you used that as well, but it wasn't wayland specific to my knowledge.
I also find Wayland more laggy and more buggy without concrete evidence of course.
It has significantly improved lately though, far more stable than it used to be.