Input is delayed while several finished frames wait in a queue to be sent out in step with the monitor’s refresh.
Why The graphics driver queues 1–3 frames ahead → Effect Input takes that much longer to show up on screen → On screen Ping is low, but controls feel heavy and sluggish
Primary owner Game team (Client development) · Also External (External)
Game team action items
Support a low-latency mode, shorten the frame queue, offer a frame cap option set slightly below the refresh rate, turn on frame pacing on phones.
External action items
Tell players to pair a variable refresh rate monitor with a frame cap slightly below the refresh rate and to turn on the graphics driver’s low-latency mode.
Ballpark numbers
At 60 Hz, each frame is 16.7 ms. When the CPU runs ahead of the GPU or the display refresh and the three-frame queue (the DirectX 11 default) fills up, 50 ms is added. With double-buffered V-Sync, a frame that took 17 ms waits for the next refresh (33.3 ms), and the previous frame is shown once more in the meantime.
On the graph
Always high · Input-to-display latency
Where to look
Compare PresentMon’s MsClickToPhotonLatency and MsAllInputToPhotonLatency (from mouse or keyboard input to output on screen) and DisplayLatency while switching V-Sync, low-latency mode, and frame caps. MsPCLatency (from when the PC receives input to when it sends the frame to the display) is recorded only if the game emits PC Latency events
Confirmed if
This latency grows by one or two frames (tens of ms) with V-Sync on or with no frame cap, and shrinks with low-latency mode or a frame cap slightly below the refresh rate. Ping unchanged
Ruled out if
Controls still feel late while latency inside the PC is low: “Display, input device, and frame generation latency.” High ping: the network side
Check with
The player’s own environment
Learn more
V-Sync (vertical sync) is a setting that sends out a new frame only at the moment the monitor refreshes the screen. Screen tearing goes away, but input is delayed by the wait for that moment, and when FPS drops below 60, it bounces between 60 and 30 and stutters. A variable refresh rate monitor shortens this wait by refreshing when a frame is ready. The same thing happens on phones. If a 30 FPS game can’t pace its frames evenly on a 60 Hz screen, the average is 30 FPS, but individual frames stay on screen for uneven times such as 49, 16, and 33 ms, which shows up as stutter (an example from the Android developer docs). Android’s frame pacing library (which evens out the intervals between frames) or the equivalent engine option reduces it.
Reduce latency with DXGI 1.3 swap chainsMicrosoft Present blocks until the queue drains, so a rendered frame waits almost one extra frame before it’s displayed; a waitable swap chain reduces this
Frame Pacing libraryAndroid (Google) On a 60 Hz screen, the previous frame is shown again when there’s no new frame; example of a 30 FPS game whose frame times become uneven, such as 49, 16, and 33 ms
PresentMon Capture Application (README-CaptureApplication.md)Intel MsPCLatency (from when the PC receives input to when it sends the frame to the display), MsClickToPhotonLatency (mouse click to screen), MsAllInputToPhotonLatency (keyboard or mouse input to screen), DisplayLatency (frame submission to output to the monitor)