Wayland developers specifically prioritize the "every frame is perfect" paradigm over performance and latency. This means there will never be an option to disable things like composition or vsync.
Also, even though it is always claimed that "X11 a is messy conglomerate of tacked on technologies and extensions" the Wayland protocol is extremely complex despite severely lacking features. And because of the strange priorities it has worse performance than X11 even for native apps. The self proclaimed "minimalist" wlroots library has more than 50000 LOC, all for moving around a bunch of overlapping windows? A bit much.
Really? I can run any app with WAYLAND_DEBUG=1 and understand every message easily.
> because of the strange priorities it has worse performance than X11
If the performance that matters to you is the tiny bit of latency caused by vsync, keep using Xorg, or Windows 95, or whatever.
Wayland is inherently much faster because it's asynchronous and doesn't have anything in between the compositor and the clients (e.g.: app <-> Xorg <-> Compiz — xorg is just a glorified message broker!).
> wlroots library has more than 50000 LOC, all for moving around a bunch of overlapping windows? A bit much
Minus 8.5k for examples, minus 7k for the big example (rootston). It's not just moving windows around. Input is inherently complex, and it supports touchscreens, touchpad gestures, drawing tablets, virtual keyboards, pointer locking (moving the camera with the mouse in first person videogames).. Also, it implements multiple backends — running on KMS/DRM, nested on Wayland and X11, and as an RDP server. Considering that it's all in C, that's a tiny number of lines. More importantly than silly metrics, it's a modern, easy to get into codebase.
How much does Xorg have, with its five or however many input systems, multiple legacy ways of direct rendering, and whatever other crap it's accumulated?
> The self proclaimed "minimalist" wlroots library has more than 50000 LOC, all for moving around a bunch of overlapping windows?
wlroots is most of a display compositor implementation, so you should be comparing it to all of the X libraries used in a compositor, and of course the server itself. I suspect the combination would easily exceed 1 million lines.
> Wayland developers specifically prioritize the "every frame is perfect" paradigm over performance and latency. This means there will never be an option to disable things like composition or vsync.
Sorry if I'm misunderstanding, but isn't this terrible? Won't it mean that video games are going to be completely unplayable on Wayland desktops?
I've never been able to get acceptable performance in a game on Wayland, but I'd always assumed that this was just because it was a work in progress and the game makers didn't test to ensure proper performance on anything but X.
> Won't it mean that video games are going to be completely unplayable
Even on my x.org desktop without compositing or any other source of extra frame delay, just turning on vsync in-game utterly destroys my ability to play Super Hexxagon[1]. If Wayland is adding additional frames of latency, I'll have to add that game (and probably any other rhythm game) to the list of reasons I cannot use Wayland.
Yes, actually Super Hexagon was one of the games I play and was thinking of when I made my comment. I find it difficult enough to play with my older computer using Optimus, but when I tried it on Wayland there was at least another 100 ms of latency. It was unplayable to the point I feel pretty sure even a TAS couldn't keep it going for long. Compositing everything with no way for apps to bypass it when necessary is profoundly stupid.
Game developers today already have to account for significant latency in display hardware, and Windows's display stack has been compositor based since Vista. So while I'm sure many of them are annoyed by it, overall it doesn't seem to be that big a deal.
This is mainly an issue if you are running windowed or borderless windowed games and under Windows there is latency too.
It is a shame that playing a game on a window is given such a low priority as personally i often prefer to do that for short term sessions where i'm waiting for something (email, some task or just pass time). Though under Windows with how busy the desktop environment often is it can be distracting. But on Linux, especially with a tiled window manager where you can have a tiny status bar above/below the window and perhaps a stripe here or there with stuff, it is perfectly normal to want to play a game in a window as opposed to fullscreen.
X11 applications are able to directly render pixels on the screen via OpenGL. In Wayland those pixels are always rendered to a buffer which will then be composed on the screen.
This doesn't mean games will be "unplayable". It just means that the performance will depend on the compositor. And since the compositor also includes functionality originally provided by window managers you might get into a situation where you can't use you tiling or whatever desktop for gaming and have to switch compositors for different applications with different priorities.
Note that Wayland introduces latency between input (you doing something) and output (seeing the result of your action), see my other posts for detail. While this latency wont make a game unplayable, it will make the experience worse for fast paced games (especially games where you control the camera directly with the mouse). However this is an issue if you are running a game in a window, the compositor should get out of the way when running fullscreen (or at least i hope it does, but that is the same with X11, some compositors see a fullscreen window and consider it perfectly fine to keep going on).
Do you actually have benchmarks and evidence showing that Wayland introduces latency over X11, or is it just a guess based on how you think Wayland works?
I mean, sure it might in some cases where you can use X11 to "directly" draw stuff on the screen, but most games would be double-buffering or triple-buffering anyway. I don't really see why Wayland would add any latency there, considering all the compositing is going to happen on the GPU anyway.
See my other posts where i explain why that would be the issue as well as how it could be addressed, but that would require hardware that AFAIK doesn't exist.
I do not have any benchmark as the only way i can think of for performing a proper benchmark that measures input-to-output latency would be using something like rigging a mouse to a robotic hand (or something like that) and capturing the screen output with a very high speed (e.g. 1000fps) camera. Sadly i do not have the necessary equipment for doing that.
The Wayland protocol is actually very simple, much simpler than X. And consider that wlroots+sway is around 100,000 LOC, but it's at least as capable as i3+xorg - which is a million lines of code.
Really claiming that it's at least as capable as xorg seems like a complete misrepresentation. Aren't some of the most common and enduring complaints about Wayland about missing features compared to X?
Uninformed and mostly outdated complaints, generally. What features are left unturned are in progress and have most of the pieces in place, and their realization will not add enough lines of code to come close to Xorg.
> there will never be an option to disable things like composition or vsync
Wait, is there a coupling between composition and vsync? I do enjoy playing games on linux, and forcing vsync enabled is an absolute non starter for me.
There is no hard dependency between composition and vsync. You can disable composition with vsync enabled, or you can have composition with novsync. (in practice they tend to be highly correlated)
However, Wayland supports neither disabling vsync nor disabling composition. Moreover, it was architected this way; there's not really any hope of disabling the compositor. Freesync looks kinda sorta like vsync if you squint at it right, so maybe there's hope for freesync in the distant future. But right now, Wayland does not support freesync, nor are there plans to implement it. Gaming on Wayland is 'lol nope' at this point, and will remain that way for the forseeable future.
Also, even though it is always claimed that "X11 a is messy conglomerate of tacked on technologies and extensions" the Wayland protocol is extremely complex despite severely lacking features. And because of the strange priorities it has worse performance than X11 even for native apps. The self proclaimed "minimalist" wlroots library has more than 50000 LOC, all for moving around a bunch of overlapping windows? A bit much.