Input lag is the delay between an action and the response you see. Press jump, move a mouse or turn a steering wheel, and several systems have to do their work before the display shows the result. The delay can exist in a completely offline game.
There is a catch when comparing numbers: a monitor review may measure only the display’s contribution, while a system test may measure the whole path from a button press to a visible change. The RTINGS test methodology describes its display measurement and distinguishes it from pixel response. Check the method before comparing two numbers labelled input lag.
Follow the action from button to screen
A useful way to investigate the delay is to follow the chain: the input device reports an action, the game processes it, the computer renders an updated image, and the display presents it. Waiting between stages matters as well as the work itself.
The exact order depends on the engine and platform. It is too simple to say that every game reads all input once at the beginning of a frame. Input processing, simulation and rendering can run on different schedules.
A polling specification describes one part of this chain. A rate of 1,000 reports per second corresponds to a one-millisecond reporting interval; it does not certify a one-millisecond journey from your finger to the screen. Switch behaviour, device firmware and everything after the report still matter.
Why a powerful computer can still feel delayed
Work can wait in a queue before it becomes visible. Microsoft’s DXGI latency guidance explains how presentation queues can leave a rendered frame waiting and how an application can schedule rendering closer to the moment the system is ready to accept it.
This is why responsiveness is not simply a contest to maximise graphics throughput. A game can produce plenty of frames while displaying input that is older than necessary. The same documentation describes a trade-off between minimising queued frames and keeping CPU and GPU work parallel. There is no single queue setting that every game should inherit from an internet checklist.
Refresh rate, frame rate and pixel response are different
Refresh rate describes how frequently a display can refresh; frame rate describes how frequently the game produces frames. At 60 Hz, a refresh period is about 16.67 milliseconds. At 240 Hz, it is about 4.17 milliseconds. These are simple reciprocal calculations, not measurements of total system delay.
A higher refresh rate creates more frequent opportunities to present changes, but it does not tell you how the game is scheduled or how the display processes its signal. Nor does a quoted pixel-response time describe the whole input path: changing a pixel’s appearance is only one stage.
When comparing tests, check the refresh rate, resolution, picture mode and measurement definition. A display-only result at one refresh rate cannot establish the responsiveness of your entire computer at another.
More displayed frames need not mean equally fresher input
Frame generation can make motion look smoother without every displayed frame representing a newly simulated response to your controls. Intel’s XeSS 2 white paper treats frame generation and latency reduction as separate, complementary features. An impressive FPS counter therefore needs context.
Low-latency options also have integration requirements. The Xe Low Latency developer guide, for example, warns against combining its scheduling with competing wait mechanisms or independent frame limiters. Follow the instructions for the actual game and supported hardware rather than enabling every setting that sounds fast.
Input lag is not the same thing as network delay
If an offline practice scene feels delayed, changing your internet provider will not fix that local input path. Online games introduce additional questions: which actions are predicted locally, which require server confirmation, and what happens when the two disagree? Our guide to netcode explores those distinctions.
Cloud gaming adds another important qualification. When the game runs remotely, input transmission, remote rendering and the returning video stream contribute to the response you experience. Microsoft’s game-streaming latency guide describes these components. It would be wrong to describe every action-to-screen measurement as entirely local.
A practical comparison you can repeat
Use a repeatable scene, change one setting at a time and record what you changed. Intel’s troubleshooting guidance suggests checking the display’s Game Mode, comparing input devices and testing synchronisation and frame-rate settings. Treat these as experiments, not guaranteed millisecond savings.
For a television, start with the mode intended for games. For a wireless controller or mouse, a supported wired comparison can help isolate a problem, but a cable is not proof of lower latency for every device. Keep the other conditions constant.
V-Sync, adaptive synchronisation and frame caps interact with the particular game and display. Compare the response alongside tearing and consistency; do not assume that one preferred combination applies universally.
Measure the thing you actually mean
A slow-motion recording can reveal a conspicuous delay, but the first visible movement of a finger is not necessarily the instant an electrical switch registers. Camera frame rate, the point on the screen being observed and repeated trials affect the interpretation.
Also separate technical delay from deliberate game behaviour. An animation, a buffered action or a rule that prevents a move from interrupting another can change when a character responds. Calling every such interval hardware lag sends the investigation in the wrong direction.
The useful goal is a reproducible explanation for your setup. A number without a measurement method is much less helpful than knowing which change actually made the same scene respond sooner.
