Live data from Hacker News

Linux latency measurements and compositor tuning

farnoy.dev

21–30 of 47 posts

Re: Linux latency measurements and compositor tuning

#21
post #16

I think this is only the top of the iceberg. I say that because I play some timing tight action games natively on elf(glibc)/linux. Let's take an example with one of the toughest: Silksong. I was trying to beat lost lace, her timings were too tight and nearly at each try I was locked in some hardly humanly dodge-able pattern combination. I knew all of her patterns by heart after zillions of tries. Then, I started to…

> I am running a Zen2, 12 cores at ~4GHz... and native x11 with xorg, sooo... the main culprit seems to lie in game engine programming and then would not completely tied to wayland programming (don't worry, I am coding my own wayland compositor, so, I am going to move to wayland, well actually designing a 'binary layout' for a wayland compositor to be accurate).

FWIW, I have similar frame pacing issues with Gnome/Mutter/Wayland with a AMD CPU + Nvidia GPU but that very issue doesn't happen with Xorg at all.

Might surface even larger issues if you go towards Wayland instead :)

Re: Linux latency measurements and compositor tuning

#25
post #17

No X11 because 'KDE drops it' is a rather silly argument for not including it, especially given that X11 is likely to trump Wayland-based systems on this metric. I'm using X11 and will continue to do so until something better comes along. Thus far Wayland is not better, just different and in several ways less functional. Yes, I do use X11 network transparency, sometimes through X2go, other times directly.

Silly author didn't take time to measure on X11, instead 'KDE drops it' author could use older version of KDE or SonicDE fork (rebranded KDE and only X11 support). And while on X11 i'm intresting how XLibre would fare in this metric, because git master of this project feels very snappy.

you do have to appreciate how much time he put into doing all the measurements he did take though

Re: Linux latency measurements and compositor tuning

#26

> Originally, I had meant to compare with X11 sessions as well, but with KDE removing them soon, I dropped it. Last time i checked X11 without a desktop compositor (very important) still provides the least latency of any environment, so even if KDE Plasma (not KDE as a whole AFAICT) drops support, there are other WMs/DEs that will work with it and have minimal latency on desktop.

KDE now supports the newer explicit sync (applications can signal when the frame is ready) and async presentation (fullscreen applications can tear rather than wait for the compositor frame sync). Fullscreen apps can also do direct scanout on Kwin now, and VRR is well supported. X11 w/o a compositor is of course still fewer steps for the data to pass through, but there is no longer anything uniquely available to that flow alone anymore.

Re: Linux latency measurements and compositor tuning

#27
post #15

When I switched to Linux from Windows last year I noticed I had a lot of keyboard input latency only when gaming. It was like I had ~100ms of input latency and it felt exactly the same as playing old school Quake I on a dial up connection without client side prediction turned on. It's like you're skating on ice with a delay when seeing the output vs when you performed the input. This was despite having a solid 60 FPS…

I abandoned Windows for a variety of reasons and while I find Linux better in many ways, the graphics and compositing situation is a bummer. To add another example, I was trying to do a screen recording the other day and it was dropping frames like crazy. I don't know who to blame, whether it's Gnome, or Wayland, or OBS, or Nvidia. But the point is my confidence in the entire ecosystem is low. I have plenty of bad things to say about Microsoft, but I think their track record is quite good when it comes to making low latency input and graphics "just work."

Re: Linux latency measurements and compositor tuning

#28

No X11 because 'KDE drops it' is a rather silly argument for not including it, especially given that X11 is likely to trump Wayland-based systems on this metric. I'm using X11 and will continue to do so until something better comes along. Thus far Wayland is not better, just different and in several ways less functional. Yes, I do use X11 network transparency, sometimes through X2go, other times directly.

Wayland is better if you have multiple monitors with high DPI and different fractional scaling settings. But yes, it is less functional than X11 in other ways.

Re: Linux latency measurements and compositor tuning

#30
post #23

Mouse pointer movement (rather than click) to display update would be amazing to get too… including X11…

this is literally the only thing that ever mattered imo

Would you mind elaborating why? What makes it more important than other inputs?
Post reply on HN