Was Wayland not architected to fix latency issues?
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.
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.
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
1. https://gitlab.freedesktop.org/wayland/wayland/-/issues/233
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.
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).
How is that bad design?
Actually is was designed because the X11 codebase was bad and nobody wanted to work on it.
This sounds like "Wayland codebase is good and everybody wants to work on it".
Wlroots exists.
Good luck using it as your graphics subsystem.
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.
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.
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.
Found it. https://magcius.github.io/xplain/article/x-basics.html
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.
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.