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.
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.
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.
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.
This is one reason why the FBDev driver is deprecated: it only supports one framebuffer per output.
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
> 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.
However, I will admit that Crinus makes some compelling points.
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 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.
Or when making say an icon you want to see it 1:1 size while working in zoomed in size, how tiling solves that?
If all of this is problematic, I don't see how tiling window managers can get into mainstream.
Really? Do you even experience them these days? The hardware nowadays is powerful enough to make them neglectable.
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?
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.
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.
Fun times...
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.
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.
And then of course there's Stadia...
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.
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.
[1] 76:37 on hyper hexxagonest!
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.
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.
This news is deeply troubling.
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.