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
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.
I was really surprised by how many games still end up feeling playable on a cross-continent Moonlight session. With ~70ms ping, there's still a lot of "realtime" games that feel fine.
Platformers tend to be a-ok, although anything with mouselook aiming tends to be really rough, since you rely so much harder on a tighter visual feedback loop for constant adjustments to aim.
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.
Somebody should measure keyboard/mouse lag for various web site/browser/operating system combinations. That would be useful. There's probably a startup in doing that as a metric.
This would be easier to do now that LLMs can learn to navigate web sites. Less custom code.
Also useful - measure it for point of sale systems.
Yeah, being in fps gaming for quite when I was younger made me quite picky about my peripherals, it's astonishing for me how much crappy stuff average people tolerate.
I sometimes use an old laptop with Fedora, with full disk encryption. When booting up, there is a text input box for the password to unlock the disk. When I hit enter, the screen content "immediately" changes (continues booting). It often feels like I hit enter before I typed the last letter of my password, but then I see that it apparently worked. The latency of that input box is just so much lower than usual, that it confuses me.
I remember one time I was playing Fortnite 1v1s with a friend and just kept losing. Something felt severely off, my game inputs felt terrible. I couldn’t quite trace my finger on what the issue was until I lost a couple rounds in a row. Turns out I had forgot to set my refresh rate to 160hz, as I had just fresh installed Windows so I could play with my friend. After that I genuinely won dang near every round. It is absolutely insane how when you switch from 60hz to 120+ you don’t really notice anything—but switching back makes you feel like your device is defective.
I once heard a rumor going around the cs:go world that Linux had lower input latency by default than windows, which made it easier to bunny hop. Is there even a semblance of truth to this?
FWIW, there's also happened quite a lot of research on latency in academia - which that page seems to completely ignore.
My group has been looking into that topic, too¹.
One of our most interesting findings (IMHO) was that for many USB devices, input latency does not follow a normal distribution but that each device has its own distribution of latencies for input events, including funny gaps².
However, with gaming hardware supporting 1000+ Hz polling, the effect of input latency should be negligible nowadays.
As a musician, it’s amazingly noticeable if there’s even a 10ms delay between hitting the key and hearing the sound, or seeing the note displayed on the screen - once I really got into digital music production and recording, it really helped to set reasonable expectations for lag in gaming, between peripherals and response rate in displays and audio lag in headphones. I still (somewhat more superstitiously at this point) default to wired devices to this day, mostly out of concern for lag.
The website notes that you can measure lag with an “expensive” high-speed camera setup.
My favorite trick, which I’ve used frequently (including in scientific publications on lag!) is to use the slo-mo cam on a smartphone. Phones will usually do anywhere from 120-240Hz. Set up the camera so it can see both your input (e.g. a side view of you pushing a button) and the display, record a video, and then pull it into a media player that supports frame-by-frame playback. You can then measure the number of frames elapsed from you pushing the button (pressing it down far enough to electrically activate it) and the corresponding reaction on screen. This gives you a cheap and easy setup capable of measuring latency down to ~4ms granularity, and doing a few repeated measurements can give you a very accurate picture of latency. Keep in mind that latency is a range (statistical distribution), not a single number, so you need repeated measurements to understand the shape of the distribution.
If you’re developing a game, you can add a prominent frame counter on screen to be captured on the video, and add the frame counter to your log output. Then you can match up the video with your game’s events, after accounting for display latency.
Ten years ago, I did some experiments building an "input lag measurement device" for touch screen devices with an Arduino. https://github.com/graup/feedback-delay-measurement
The research was related to QoE in cloud gaming. At that time, some Android devices had insane lag (125 ms+), whereas Apple devices were already consistently around 30ms. I assume this isn't a problem anymore nowadays.
Check out “Game Feel: A Game Designer's Guide to Virtual Sensation” by Steve Swink.
To some extent, responsiveness is a perception based on expectations derived from the visual and acoustical elements of a game. So on top of engine-level optimizations, there are artistic tricks that can further improve the sense of responsiveness.
Think Kiki and Bouba, and how each one would move, race and fight.
> it can say that it’s a controller and it will give the bus address to talk to and a polling rate.
Many moons ago (over 25 years) I was an EE hobbyist working with an inventor, working adjacent to a major game controller manufacturer. The controllers I was prototyping weren't getting polled by the OS. I was just using the USB HID Class and sending "Button Up" and "Button Down" messages using Interrupt Transfers. Are game controllers using Isochronous transfer now or is there some other method that's developed in the last quarter century?
18 comments
[ 3.2 ms ] story [ 47.6 ms ] threadThe 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'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.
Platformers tend to be a-ok, although anything with mouselook aiming tends to be really rough, since you rely so much harder on a tighter visual feedback loop for constant adjustments to aim.
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.
This would be easier to do now that LLMs can learn to navigate web sites. Less custom code.
Also useful - measure it for point of sale systems.
My group has been looking into that topic, too¹. One of our most interesting findings (IMHO) was that for many USB devices, input latency does not follow a normal distribution but that each device has its own distribution of latencies for input events, including funny gaps².
However, with gaming hardware supporting 1000+ Hz polling, the effect of input latency should be negligible nowadays.
¹) https://hci.ur.de/projects/latency
²) https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB...
My favorite trick, which I’ve used frequently (including in scientific publications on lag!) is to use the slo-mo cam on a smartphone. Phones will usually do anywhere from 120-240Hz. Set up the camera so it can see both your input (e.g. a side view of you pushing a button) and the display, record a video, and then pull it into a media player that supports frame-by-frame playback. You can then measure the number of frames elapsed from you pushing the button (pressing it down far enough to electrically activate it) and the corresponding reaction on screen. This gives you a cheap and easy setup capable of measuring latency down to ~4ms granularity, and doing a few repeated measurements can give you a very accurate picture of latency. Keep in mind that latency is a range (statistical distribution), not a single number, so you need repeated measurements to understand the shape of the distribution.
If you’re developing a game, you can add a prominent frame counter on screen to be captured on the video, and add the frame counter to your log output. Then you can match up the video with your game’s events, after accounting for display latency.
To some extent, responsiveness is a perception based on expectations derived from the visual and acoustical elements of a game. So on top of engine-level optimizations, there are artistic tricks that can further improve the sense of responsiveness.
Think Kiki and Bouba, and how each one would move, race and fight.
Many moons ago (over 25 years) I was an EE hobbyist working with an inventor, working adjacent to a major game controller manufacturer. The controllers I was prototyping weren't getting polled by the OS. I was just using the USB HID Class and sending "Button Up" and "Button Down" messages using Interrupt Transfers. Are game controllers using Isochronous transfer now or is there some other method that's developed in the last quarter century?