Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

marco-nett.de

Post reply on HN
Print view View original

131–140 of 297 posts

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#131

Post by michaelmrose »

datakan wrote: post #13
cgyvbunji wrote: post #3

He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.

I've been using Linux since the mid 1990's. I'm no newbie to any of this. I literally can't tell the different between X11 and Wayland when using either of them and I don't care about all the arguing. This is just Vim vs Emacs and Gnome vs KDE all over again. At this point when I see people complaining about it I just click off the page. It's all stupid and pointless.

No. Wayland has been in development for 17 years. People have been claiming its been ready for prime time when it wasn't for a surprising portion of that time while it had substantial deficiencies while the boring old shit continued to work fine.

It has been ready for users whose sole usage is an editor a terminal and a browser on their single screen intel laptop as long as they didn't also open youtube since 2015.

Imagine the boss's nephew joins the firm. He knows less than nothing and is worse than useless everything he touches turns to shit. People understandably complain. After 10 years of development and other people's time he is now moderately capable at his job. People still bitch. They aren't lying or wrong. They just aren't current.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#132

Post by zaik »

teodorlu wrote: post #79

Very interesting! Latency numbers are written with three significant digits (4.21 ms). I'm curious about the accuracy of the measurement device. If it can measure tens of microseconds, I'm impressed. If it can't, the conclusions in this article should be taken more coarsely.

> it starts collecting samples from the photodiode (every ~24 µs).

They also have repeated measurements which improves the precision.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#133

Post by PunchyHamster »

datakan wrote: post #13
cgyvbunji wrote: post #3

He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.

I've been using Linux since the mid 1990's. I'm no newbie to any of this. I literally can't tell the different between X11 and Wayland when using either of them and I don't care about all the arguing. This is just Vim vs Emacs and Gnome vs KDE all over again. At this point when I see people complaining about it I just click off the page. It's all stupid and pointless.

well according to post, coz they are very similar. but xwayland doubles it

which is still half a frame at best so I think any blame here would be just on a particular game being slow on inputs

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#134

Post by slackfan »

Aurornis wrote: post #40
prhn wrote: post #11

Awesome article. I switched my daily driver / gaming rig to Fedora a few months back. Everything seems snappier compared to Windows, but not sure if it’s in my head, and I’ve been very curious about gaming input latency. This helps answer some questions. I recently switched to hyprland and I’m very interested how that fits in these results. hyprland uses Wayland so I hope the author might revisit now that hyprland is…

With the exception of XWayland, all of the tests had input latencies within a very small range. No human could tell them apart by those latency differences alone. I would be amazed if someone could notice the 3ms difference jump to XWayland. The difference could be much larger on a slower monitor. However the differences between Wayland and X11 as protocols is negligible. XWayland as an implementation looks to have a…

I can tell down to about a 3ms difference in lag. Actually even down to 1ms, it's not all its cracked up to be, lemme tell you.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#135

Post by TiredOfLife »

Narishma wrote: post #52
0x457 wrote: post #41

Earlier quoted context omitted.

Consoles target 30fps though. Very rarely they target 60fps and even less rarely they can reach that.

That's outdated information. Most PS5 and the equivalent Xbox games target 60 fps nowadays. It's usually huge news when a game is only 30 fps.

That's outdated information. Most PS5 and the equivalent Xbox games target 30-40 fps nowadays. With an additional performance mode that targets 60 fps, but with lower quality

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#136

Post by Havoc »

bee_rider wrote: post #73
Havoc wrote: post #47

Using Wayland (hyprland) for daily driver and it's the happiest I've been with an OS in a long time on feel. Feels crisp in that spartan way that windows & macos just don't - no animations, taskbar, popups or god knows what else.

That’s interesting. Hyprland, spartan? It’s the fancy everything-and-the-kitchen-sink tiling WM, isn’t it?

Spartan...haha...I mean it's all relative. Certain relative to the other two boxes I use daily - macos & win.

I do know it is favoured by ricers with animations & transparency but I just use it to tile stuff. Think I selected it over sway & i3 due to wayland support at the time. Not sure.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#137

Post by delusional »

Hey, I made one of these too[1]. One of the cool things about my implementation is that the sample loop is carefully written in cycle counted assembly to sample the ADC of the teensy 2.0 at the absolute maximum frequency. I like your blogpost a lot more than mine though.

[1] Github: https://github.com/DelusionalLogic/Frametime, Blogpost: https://www.jnsn.dev/posts/frametime/, and followup: https://www.jnsn.dev/posts/fastisslow/

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#138

Post by gf000 »

hackernudes wrote: post #61
retatop wrote: post #42

Earlier quoted context omitted.

Isn't Wayland always one frame delayed compared to Xorg to avoid tearing or has that been changed? If so, his very high refresh rate would minimize that effect

I don't think there was ever a design to be one frame behind. Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout"). Also some wayland compositors keep track of timing and dela…

And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#139

Post by seba_dos1 »

upboundspiral wrote: post #58
haunter wrote: post #37

SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope >Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.

gamescope is a custom wayland compositor that Valve built for gaming... In steam big picture mode there is no xwayland or anything, just gamescope. What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter). gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...

What you're saying doesn't make any sense. Gamescope is essentially a XWayland-only compositor (with some basic xdg-shell support that's disabled by default). All games on SteamOS go through XWayland.

It doesn't yet mean that it suffers from the latency measured in the article, as the problem could very well be in something else, such as how KWin integrates with XWayland or how GPU drivers interact with it (especially that Nvidia drivers have a history of making XWayland suffer).

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#140

Post by wasmperson »

datakan wrote: post #13
cgyvbunji wrote: post #3

He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.

I've been using Linux since the mid 1990's. I'm no newbie to any of this. I literally can't tell the different between X11 and Wayland when using either of them and I don't care about all the arguing. This is just Vim vs Emacs and Gnome vs KDE all over again. At this point when I see people complaining about it I just click off the page. It's all stupid and pointless.

Sure Wayland works fine. What you're not seeing is the hours and hours of volunteer labor wasted to get it to that point. Time that could have been spent working on features users actually cared about, now wasted "adding wayland support" to your favorite applications. If you could quantify it, the waste would be borderline criminal:

- Effort spent writing sway that could have been spent improving i3

- Effort spent writing GNOME-Wayland that could have been spent improving GNOME

- Effort spent writing KDE-Wayland that could have been spent improving KDE (much of this work duplicated effort with GNOME-Wayland)

- Effort spent writing wlroots to try and mitigate the effort being wasted by people writing bespoke compositors

- Wine/Proton devs needing to waste time getting every windows application to work in Wayland

- Firefox needing to target both Wayland and X

- A bunch of graphical toolkits and window managers that were working perfectly fine but will now be "left behind" since they lack the maintainers to support a porting effort

- low-level toolkits like SDL needing to implement their own window decorations now that they're not guaranteed to be provided by the OS (what?!)

What Wayland proves to me is just how easy it is for a small number of developers to unintentionally sabotage productivity in a much larger project.

Post reply on HN