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.
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.
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.
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.
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.
> 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.
floatboth|6 years ago
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.
andreyv|6 years ago
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.
Crinus|6 years ago
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.
Tharkun|6 years ago
kbumsik|6 years ago
Really? Do you even experience them these days? The hardware nowadays is powerful enough to make them neglectable.
mspnp|6 years ago
sprash|6 years ago
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.
floatboth|6 years ago
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?
tadfisher|6 years ago
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.
bscphil|6 years ago
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.
ddevault|6 years ago
ilikehurdles|6 years ago
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.