So looks like performance wise it's 99.9% of the way there including on Xwayland which is amazing. How's input lag though?
Announcement
Collapse
No announcement yet.
Ubuntu 20.04 GNOME X.Org vs. Wayland Session Performance Impact For Gaming
Collapse
X
-
Originally posted by tildearrow View Post
Did you just tell us that GNOME won and it should be the only desktop?!
It's enough. You are A FREAKING DISGRACE.
*sighs* No, you know what... I can't tolerate this. I am going to delete your post.
A lot of people love your contributions. Stop getting at each other's throat, be it via subtle stabs (which can be rightfully mistaken for trolling attempts) or blatant attacks. Please.
144Hz tildearrow
Also, what is up with moderation in these forums, in general? I came here to learn useful things such as: which MR didn't get into Mutter and why, what can we expect in the short term, and so on.
If you are all so passionate about flamewars, create the ultimate mega X.Org VS Wayland topic and stick to it. Don't pollute every other topic because of your inability to keep your protagonism in check.
Sincerely,
everybody
- Likes 1
Comment
-
Originally posted by 240Hz View PostIts embarrassing that after 15 years of development and millions spent, the supposedly superior wayland still cannot beat the "old and bloated X", not in performance or features.
- Likes 3
Comment
-
Originally posted by ernstp View PostIf we pause the flamewars a bit, which games have you been able to get running with SDL_VIDEODRIVER=wayland?
Most Linux native SDL games should in theory work in this mode, if you have new enough libSDL.
The libSDL in Steam doesn't have the wayland backend compiled in though I guess.
I tried running Jupiter Hell from Steam with SDL_VIDEODRIVER=wayland by copying in a newer libSDL and that seemed to work!
- Likes 1
Comment
-
Originally posted by jacob View Post
Running Ubuntu 20.04. I don't know what you mean by "syncing output on input". As I said, I know that the lag problem exists in some cases, but it's not pervasive and not something that is inherent to Wayland. Under Wayland, both screen compositing and input processing are handled by the same process (unlike how it's done on X11) so it comes down to that process' implementation, the protocol is not involved in this. With X11 you *HAD THE IMPRESSION* that there never was a lag problem because pointer movement was handled by the X server which made it responsive regardless of how garbage the compositor was - but only the mouse pointer, not reacting to actual events. Early Wayland compositors such as Gnome Shell were ports of X11 compositors, which obviously didn't fare well (not properly multithreaded etc).
My only real-world experience with Wayland is with GNOME, until 3.32 reactivity and lag were (occasionally) a problem, by 3.34 it had improved substantially, on 3.36 it's better than it has ever been with a composited X11 desktop and on 3.36 with RR enabled is as close to perfection as it gets.
The only useful mention I could find with a quick DDG search is in this page on Arch Linux' bug tracker. Is this correct?
Code:gsettings set org.gnome.mutter experimental-features "['rt-scheduler']"
- Likes 1
Comment
-
Originally posted by sdack View PostFrom the start was Wayland given credit for becoming the better, securer and faster windowing system. And after 10 years are we still not seeing it.
Originally posted by sdack View PostIt then didn't take 10 years to develop DXVK
- Likes 1
Comment
Comment