The immediately noticeable improvement with wayland is with respect to screen tearing, especially in multi-monitor rotated configurations. Screen tearing has always been an issue on x11, and while intel/amd drivers do a decent job in basic cases, things that don't work will likely never work given that x11 is mostly deprecated.
Screen tearing has not been an issue on X11 for like... a decade? Granted, that's after development on Wayland started.
Also I just don't get this obsession with screen tearing. I've experienced it on occasion in other context and I... just kinda don't care about it? Certainly if you're a video editing/creating/whatever professional, it actually matters for your job, but otherwise it's just cosmetic, and often hardly noticeable at all.
This is just one very easy to replicate example. There are a bunch of other seemingly simple tasks that lead to some rather hideous tearing in X.
mpv has a whole FAQ section about it:
https://github.com/mpv-player/mpv/wiki/FAQ#tearing
Some of the solutions presented there are not mpv-specific, and some of them may even actually help.
A nice made-up issue but it's made up.
Famously stable, reliable, and uncomplicated.
Option "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
Intel, AMD and X.org modeset driver: Option "TearFree" "On"
You can even enable it at runtime: $ xrandr --output $output --set TearFree on
Nouveau:No bloody idea, nouveau is broken. Sorry to break it to you or you're either using NVIDIA binary drivers or buy a different GPU.
The issue does not exist. Period. If you have troubles enabling these options, I'm sorry for you. Linux in 2022 still requires to choose your HW wisely. If you don't like it/have a different PoV, it's not my problem, it is the status quo.
(WW) modeset(0): Option "TearFree" is not usedYour report is not widely shared on the Internet either. Arch Wiki, unix.stackexchange.com, r/Linux, and others - none of them confirm it either.
I'm almost sure it's down to your particular HW configuration.
"And now you have done something X11 cannot do - eliminated screen tearing with the absolute minimum latency cost possible.
"This [is] fantastic.... And like, this is the first time I’ve ever seen the vsync setting in a game actually sync the game up with the vblank interval in a way that matters. It works for games in wine. It’s amazing. I have never experienced gaming on Linux that looked this smooth in my life."
I much prefer Sway. It handles output management much better than i3 (because it’s integrated and integrated well rather than being entirely up to you with xrandr—so this probably wouldn’t apply to full desktop environments like GNOME or KDE), supports mixed-DPI environments, properly supports high-DPI (though I’ve also been using patches for fractional scaling since I want 1.5×), avoids all tearing (which was what really surprised me when I first ran i3, I’d forgotten what the tearing was like), and supports my XF86AudioMicMute key (key code 256; it took a little effort to get it to work, involving dumping the xkb keymap and adding in a suitable entry, but I think that it’s literally impossible to support under X, though you may be able to remap it to a different key like F20 in some way at a lower level, but my attempts at that failed).
It’s not been without its troubles. Screen sharing is only possible at the screen granularity rather than individual windows, and I think Zoom is still broken because they did things stupidly in the past (using a GNOME screenshot API many times per second instead of the compositor-neutral screen sharing API that did exist when they implemented their thing) and are still unravelling them. I’ve also had a couple of apps require tweaks to unbreak, e.g. https://github.com/CadQuery/CQ-editor/issues/266, if you build it with a version of Qt that supports Wayland (the default, though their first-party distribution doesn’t), you have to explicitly tell it to use xcb instead of wayland or it crashes on startup. But honestly that’s all I can think of.
Oh, one more thing, I guess. Cursor sizing is comically broken in Sway. With `seat seat0 xcursor_theme Adwaita 96`, I get cursors at at least five different sizes when hovering over different windows. Some ignore it and use the default size multiplied by the scaling factor. Some use it but ignore the scaling factor. Some use it and multiply by the scaling factor. Some use it and multiply by the scaling factor rounded up to the next integer. Some do different things altogether. I haven’t diagnosed it all yet.
But as a user the experience is noticeable superior. One thing I noticed that I wasnt expecting was that things actually got subjectively snappier.
That might be, but by definition those that are the devs decide what everyone uses.
I mean, if you're willing to pay them to work on something else, fine, but as long as this stuff is run mostly by volunteers, that's kind of the score.