Can you even disable desktop composition in Wayland? One of the reasons I hate Windows is that I'm forced to use composition, which provides nothing to me.
If visual perfection is nothing to you, if you love screen tearing, slow window redraw when moving, Windows 95-esque window trails, etc. — keep using Xorg.
Wayland is a protocol fully designed around composition. Clients have their own buffers, the server composites them. There is no way to draw directly to the screen, because we're not in the 90s with 640K of RAM and there's no reason whatsoever to implement the crappy way of rendering windows.
Forced composition and vsync is a mistake for gaming.
The added output latency is unacceptable, especially for first-person shooters. A little tearing is nothing compared to the vsync lag.
If Wayland wants to replace X.org, then it should support also this use case. But full composition being mandatory isn't very encouraging in regard to this.
Games still can render more FPS than mandated by vsync.
I tried playing sauerbraten (with SDL2) on sway other day, it was butter smooth (no tearing) with vsync off in game, and I felt no input lag unlike when I switch vsync flag on in game which limits FPS.
It probably does triple buffering, but somehow on sway it worked better than triple buffering of intel's xorg driver back when I tried that.
Composition forces latency tied to the refresh rate of the composited output and is the only reason i do not like it and disable it where possible. For me this latency makes Wayland imperfect.
I do not love screen tearing, i just do not mind it at all unless i am watching a movie (where i can enable vsync in the player).
Slow window redraw when moving is something i haven't seen since i had a 386. Even my Pentium could blit windows around.
Windows 95-esque window trails are only a thing if the process associated with the window is stuck. Note, btw, that there is nothing that forbids the X server to cache such windows if it detects that the client doesn't respond to messages after a while - which btw is what Windows does since XP. It is just that nobody implemented it.
> Wayland is a protocol fully designed around composition.
Which was a mistake.
> Clients have their own buffers
Which was a mistake.
> the server composites them
At some other point after the client has marked its window as being updated, meaning that you have around two frames of latency (first frame is your input being sent to the application while the application is drawing itself, meaning that the input will be processed later so the response to your input is a frame late and second frame is the application notifying the window server that the window is outdated while the window server is drawing the output, meaning that the new contents will be used in the next frame).
> There is no way to draw directly to the screen
Which was a mistake.
> because we're not in the 90s with 640K of RAM
If 640KB of RAM didn't limit being able to have direct access to the screen and fast response times, 640GB of RAM shouldn't either. The new design is just misguided garbage that has nothing to do with available resources and everything to do with developers not giving two thoughts about uses outside of their own (note: X11 allows you to have both composited and non-composited output, so people who like composition can use it as can people who dislike it, Wayland forces composited output so people who dislike composition cannot use it).
> there's no reason whatsoever to implement the crappy way of rendering windows
Yes, wasting resources with every application having to maintain their own buffer for each window's contents even though those contents will not change for the vast majority of the window's lifetime for most windows is crappy. Though that is only a minor reason for why Wayland sucks.
> At some other point after the client has marked its window as being updated, meaning that you have around two frames of latency (first frame is your input being sent to the application while the application is drawing itself, meaning that the input will be processed later so the response to your input is a frame late and second frame is the application notifying the window server that the window is outdated while the window server is drawing the output, meaning that the new contents will be used in the next frame).
Not every action takes an entire frame. The timeline can easily be like this:
0ms: old frame starts to output
4ms: input happens, application wakes up
9ms: application finishes rendering
15ms: compositing happens
16ms: new frame starts to output
There's nothing about compositing that requires it to add any significant lag on top of rendering time plus transmit time. If input shows up while you're already drawing? That could happen without compositing. Just draw again or do whatever you'd do without compositing.
> Yes, wasting resources with every application having to maintain their own buffer for each window's contents even though those contents will not change for the vast majority of the window's lifetime for most windows is crappy.
Why waste time redrawing it if it's not changing? And a full-screen window on 1080p is only using 6MB for that buffer. Compared to the processes I'm running, the frame buffers are quite lightweight.
I thought freesync support in modern GPUs meant that they weren't restricted to a fixed refresh rate anymore, and that pixels would then just be "composited" and appear on screen as quickly as possible regardless of their on-screen positioning. Then by using a single fixed buffer that covers the whole screen, this essentially gives you the equivalent to "compositing being disabled".
The only way to avoid the composition latency is to have the entire composition be done when the GPU is sending the final image to the monitor (note that performing composition using the GPU via OpenGL or whatever is not the same thing even if both are done using the GPU), pretty much like what "hardware mouse cursor" gives you. This would require GPUs to support an arbitrary number of transformable overlapping surfaces (where a single surface=a single toplevel window) and applications being able to draw to these surfaces directly without any form of intermediate buffering (which is important to avoid the initial late frame latency).
Now, it isn't like it is impossible to make a GPU with this sort of functionality since GPUs already do some form of composition already, but AFAIK there isn't any GPU currently on the market that can do all the above. At best you get a few hardcoded planes so you can implement overlays for fullscreen content.
And of course none of the above mean that you have to use Wayland, the X server could perform toplevel window composition itself just fine.
Who even moves windows around on a desktop? Surely everyone is using tiling window managers these days, instead of relying on that sort of nonsense? No? Oh well, I'll keep hoping for tiling to become mainstream.
I personally don't consider it just a small improvement. Tearing drives me crazy and I'm comfortable sacrificing a frame to make sure it never happens.
However, I will admit that Crinus makes some compelling points.
I should note (i already mention it in my other post but it is in a little bit in a sea of words) that disliking tearing and wanting to run a desktop environment free of it is perfectly fine and X11 does allow for that - there is nothing in it (considering extensions too) that prevents such use and if there are bugs then these are bugs that can be fixed.
My issue with Wayland when it comes to composition is that it forces it whereas in contrast X11 just enables it - but doesn't force it.
It is the good old "having options" argument which, for some reason, always comes up when GNOME and Red Hat projects are involved.
(just as a note, composition isn't my only issue with Wayland, i have other issues with it being short-sighted and needlessly limited, but these are outside the current discussion)
The wording of the parent comment - specifically "Wayland is a protocol fully designed around composition [...] There is no way to draw directly to the screen" - made me think that this is a case originally of idealism, that when seen to be naive, presses on into diseased dogmatism. Some people decide that for example 'composition' is the be all and end all, and all other aspects are secondary to it, or less. Therefore if useful functionality is dropped, so be it.
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.
Wayland is a protocol fully designed around composition. Clients have their own buffers, the server composites them. There is no way to draw directly to the screen, because we're not in the 90s with 640K of RAM and there's no reason whatsoever to implement the crappy way of rendering windows.