I wish they included the window compositor as something that can introduce latency because I'd like to learn more about it.
When I switched from Windows to Linux on the same hardware I noticed a lot of keyboard input latency when playing games, at least 150ms. This only happens to me with niri, KDE Plasma (Wayland) feels identical to Windows. So did Hyprland. I'm able to reproduce it on multiple systems when I have a 4k display running at 1:1 native scaling. On AMD cards, turning off v-sync helped reduce it but it didn't remove it. With an NVIDIA card, turning off v-sync made no difference. I believe it's semi-related to that 4k display because when I unplug that display and use my 2560x1440 monitor, it's much less noticeable despite getting a solid 60 FPS with both monitors. All that to say, there's certainly a lot more than your input device, GPU and display playing a role.
If anyone played Quake on a dial-up connection with client side prediction turned off, that is the exact same feeling. It's pressing a key and then seeing the screen update X ms afterwards.
Input lag is one of those things you feel before you can explain it. Good to finally have a resource that breaks down the full chain — controller, engine, display — instead of just blaming the monitor like everyone does
The engine section is the part most developers seem to ignore. A locked 60fps doesn't mean 16ms latency, and that gap make me surprise
I used to get into arguments all the time about how triple-buffering reduces latency, and I think it's because we lacked resources like this; people assume it adds the additional back buffer to a queue, when the traditional implementation "renders ahead" and swaps the most recently-completed back buffer. It's a subtle difference but significantly reduces the worst-case latency vs. a simple queue.
I think most people get their information from help blurbs in settings menus for PC games, which are often hilariously vague or incorrect.
One area of focus missing here is game streaming / remote play (Steam Link, Moonlight, etc. over a local network).
I've come to accept input lag, but mostly play games where it doesn't matter (simple platformers, turn-based games, etc). I know steam link from my home desktop to my ~5 year smart TV is adding latency to my inputs – though I can't tell if it's from my router, desktop, or TV – but I've come to accept it for the convenience of playing on the couch (usually with someone watching next to me).
I know some blame is on the TV, as often if I just hard-reset the worst of the lag spikes go away (clearly some background task is hogging CPU). And sometimes the sound system glitches and repeats the same tone until I reset that. Still worth putting up with for the couch.
quite a few syntactical errors on this website. I’d suggest running it through an LLM and telling it to fix the mistakes without altering anything else!
I wish they included the window compositor as something that can introduce latency because I'd like to learn more about it.
When I switched from Windows to Linux on the same hardware I noticed a lot of keyboard input latency when playing games, at least 150ms. This only happens to me with niri, KDE Plasma (Wayland) feels identical to Windows. So did Hyprland. I'm able to reproduce it on multiple systems when I have a 4k display running at 1:1 native scaling. On AMD cards, turning off v-sync helped reduce it but it didn't remove it. With an NVIDIA card, turning off v-sync made no difference. I believe it's semi-related to that 4k display because when I unplug that display and use my 2560x1440 monitor, it's much less noticeable despite getting a solid 60 FPS with both monitors. All that to say, there's certainly a lot more than your input device, GPU and display playing a role.
If anyone played Quake on a dial-up connection with client side prediction turned off, that is the exact same feeling. It's pressing a key and then seeing the screen update X ms afterwards.
'Input lag' should really be called 'Output lag', as most of it usually comes from the display device and/or graphics pipeline, not input devices
Input lag is one of those things you feel before you can explain it. Good to finally have a resource that breaks down the full chain — controller, engine, display — instead of just blaming the monitor like everyone does
The engine section is the part most developers seem to ignore. A locked 60fps doesn't mean 16ms latency, and that gap make me surprise
I used to get into arguments all the time about how triple-buffering reduces latency, and I think it's because we lacked resources like this; people assume it adds the additional back buffer to a queue, when the traditional implementation "renders ahead" and swaps the most recently-completed back buffer. It's a subtle difference but significantly reduces the worst-case latency vs. a simple queue.
I think most people get their information from help blurbs in settings menus for PC games, which are often hilariously vague or incorrect.
One area of focus missing here is game streaming / remote play (Steam Link, Moonlight, etc. over a local network).
I've come to accept input lag, but mostly play games where it doesn't matter (simple platformers, turn-based games, etc). I know steam link from my home desktop to my ~5 year smart TV is adding latency to my inputs – though I can't tell if it's from my router, desktop, or TV – but I've come to accept it for the convenience of playing on the couch (usually with someone watching next to me).
I know some blame is on the TV, as often if I just hard-reset the worst of the lag spikes go away (clearly some background task is hogging CPU). And sometimes the sound system glitches and repeats the same tone until I reset that. Still worth putting up with for the couch.
Build an sffpc, have it by the tv :)
quite a few syntactical errors on this website. I’d suggest running it through an LLM and telling it to fix the mistakes without altering anything else!
Good to know it's human written