Display Times Explain Why a Smooth Frame Time Graph Can Still Look Bad in Games

Frame time graphs remain one of the best ways to measure PC game performance, but they do not always show what is actually happening on your monitor. A game can report steady frame times while still showing judder, tearing, or uneven motion. That is where display times become important.

Frame times measure how often a game submits frames. Display times measure how often the visible image on the monitor actually changes. In simple terms, frame times describe what the game engine is doing, while display times are closer to what you see during gameplay.

This distinction matters more now because PC gaming uses Variable Refresh Rate, V Sync, frame limiters, borderless window modes, graphics driver scheduling, and frame generation. All of these can change the relationship between the frame a game produces and the image that finally appears on screen.

Frame Times Measure the Game While Display Times Measure the Screen

Most benchmarking tools use frame times, often shown as MsBetweenPresents in PresentMon. This measures the time between two Present calls from the game.

A lower number means a higher frame rate. For example, 16.67ms is about 60 FPS, 8.33ms is about 120 FPS, and 4.17ms is about 240 FPS.

Frame time graphs are useful because large spikes can reveal shader compilation stutter, CPU bottlenecks, asset streaming issues, storage delays, or uneven game engine pacing.

However, a game submitting a frame does not mean that frame immediately appears on the monitor. It may be queued, synchronized to a refresh cycle, replaced, delayed, or affected by tearing and frame generation.

V Sync Can Look Better Than Its Frame Time Graph Suggests

The comparison between V Sync and an external frame limiter shows why display times matter. In one test, V Sync produced slightly uneven present based frame times, which could make it appear less smooth on paper.

But display time measurements showed that the visible frame delivery was extremely consistent. The variations around the 8.33ms target were so small that they would be very difficult to notice during gameplay.

An external RTSS frame limiter showed the opposite result. Its frame time graph looked clean, but display times were less consistent when V Sync was disabled. The result was visible judder and screen tearing, despite the frame time graph looking reasonable.

This does not mean external limiters are bad. It means a limiter should not be judged only by its present based frame times.

DLSS Frame Generation Can Look Worse in Benchmarks Than It Feels

NVIDIA DLSS Frame Generation is another case where display times are more useful. Present based frame times can make frame generation look poorly paced because generated frames may be added after the game submits its frames.

A capture based only on MsBetweenPresents may show severe frame pacing problems and poor percentile results. But when the same run is measured with display times, the visible frame cadence can appear much smoother.

This is important for reviewers and benchmark creators. A graph can be technically correct while still measuring the wrong part of the rendering pipeline for the question being asked.

Both Metrics Should Be Used Together

Frame times are still essential for understanding why a game stutters. They help identify whether a problem comes from the CPU, GPU, shader compilation, storage, memory, or the game engine itself.

Display times are better for answering a different question: does the game actually look smooth on the screen?

The best gaming performance analysis should use both. Frame times explain how the game produces frames, while display times show how those frames are delivered to the display. Modern benchmarking needs both metrics to give a clearer picture of real gameplay smoothness.