Display Times, Frame Times, And The Truth About Smoothness

In the world of PC gaming performance analysis, we tend to obsess over frame times, and for good reason. A simple average FPS number can be extremely misleading, while a frame time graph can immediately show you whether a game is delivering frames smoothly or whether it is suffering from stutters, hitches, CPU/platform bottlenecks, or other forms of inconsistent frame pacing.

However, as useful as frame times are, there is one major problem with relying on them alone: they do not always tell us what the player actually sees on the monitor.

This is especially important nowadays, as modern PC gaming is no longer just a simple matter of the game rendering a frame, presenting it, and the monitor immediately showing it. Between Variable Refresh Rate (VRR), Vertical Sync (V-Sync), external framerate limiters, uncapped framerates that exceed the monitor's maximum refresh rate, borderless presentation paths, graphics driver-level scheduling, and frame generation technologies, the relationship between the game's frame output and the final displayed image can get surprisingly complicated, and that’s exactly where display times come in.

Frame times, or more specifically MsBetweenPresents in Intel PresentMon terminology, measure the time between two application Present() calls. In simpler terms, they tell us how often the game submits frames. Display times, or MsBetweenDisplayChange, measure the time between actual displayed image changes. In even simpler terms, they tell us how often the image shown to the player actually changes.

Both metrics are useful, but if the question is: “How smooth does the game look on my monitor?”, then display times are often the better metric.

That does not mean frame times are useless. Far from it. Frame times are still incredibly valuable for assessing what the game engine is doing. If a game has shader compilation stutter, CPU/platform-side stalls, asset streaming hitches, or uneven simulation/render pacing, then frame times will often expose that very clearly. But if we are specifically trying to judge perceived smoothness — meaning the consistency of frame delivery to the display — then we need to care about what actually reaches the monitor, not just what the game attempted to present.

In this article, we will explain the difference between frame times and display times, why the distinction is important, and why display times can give us a more accurate picture of perceived smoothness in two scenarios: V-Sync vs an external framerate limiter and NVIDIA DLSS Frame Generation frame pacing behavior with MsBetweenDisplayChange vs MsBetweenPresents.

Frame Times vs Display Times: What Is The Difference?

Before we go any further, let us establish the basic terminology. When most PC gamers, reviewers, or benchmarking tools talk about frame times, they are usually talking about the time between consecutive frames submitted by a game. In PresentMon terms, this is represented by MsBetweenPresents.

A lower frame time (conventionally measured in milliseconds or ms) means a higher framerate (conventionally measured in frames per second or FPS). For example, a 16.67 ms frame time corresponds to a framerate of roughly 60 FPS, 8.33 ms corresponds to roughly 120 FPS, 4.17 ms corresponds to roughly 240 FPS, and so on.

This is why frame time graphs are so useful. If a game is running at 120 FPS, we would ideally like to see frame times hovering around 8.33 ms. If the graph suddenly spikes to 33 ms, 50 ms, or 100 ms, then something went terribly wrong during that moment, and the player likely perceived a nasty stutter or hitch.

However, a Present() call does not represent what users actually see on their screens. A frame can be presented by the game, then queued/buffered, delayed, synchronized to a refresh interval, dropped, replaced, partially displayed as a tear, or affected by the monitor's own refresh behavior. This is why MsBetweenDisplayChange exists. Instead of measuring the application's present cadence, it measures the cadence of actual visible image changes at the display level. This is an important distinction, because visual smoothness is not experienced at the Present() call, but rather at the display level.

To put it simply, frame times are closer to what the game is doing. Display times are closer to what the player is seeing.

Why This Distinction Is Important For PC Gaming Benchmarks

Historically, frame time analysis was already a major improvement over average framerate reporting. A game could average 120+ FPS and still feel awful to play if the frame delivery was constantly spiking. This is why 1% low and 0.1% low FPS numbers became so popular in the first place: they attempt to capture the worst parts of the performance curve that average FPS completely hides.

But as PC presentation pipelines have become more complex, we now have to ask a slightly different question: are we measuring how consistently the game submits frames, or are we measuring how consistently the display changes? Those two things are often similar, especially in a simple, well-behaved, non-VRR, non-frame generation, non-composited scenario. But they are not always identical, and when they diverge, the difference can be very important. This is why a frame time-only overlay can sometimes look worse or better than the experience. The overlay may not be “wrong” in the data it is reporting. It may simply be reporting a different stage of the pipeline.

For that reason, this article focuses on CapFrameX/PresentMon captures that compare MsBetweenPresents and MsBetweenDisplayChange directly. The goal is not for you to “trust our eyes”, but rather to show how the data change depending on whether we measure the game's present cadence or the display's actual visible cadence.

For our testing, we performed CapFrameX captures in an adequate Resident Evil Requiem test scene, with a target framerate/frame time of 120 FPS/8.33 ms, respectively, for the VSync vs external framerate limiter runs, and with an unlocked framerate target for our DLSS Frame Generation capture. Also, the captures were performed on our desktop test system, which has the following relevant specs:

• CPU: Intel Core i7-14700K
• RAM: 32 GB DDR5-7000 CL34
• Storage: 2 TB PCIe 4.0 NVMe SSD
• GPU: NVIDIA GeForce RTX 4090
• Operating System: Windows 11 25H2
• All system firmware, BIOS, OS updates, and graphics drivers were fully updated before testing.

Important note: To log display times with CapFrameX, the "use MsBetweenDisplayChange metrics" option must be enabled in its settings/options section:

First scenario: V-Sync vs External Framerate Limiter

The first scenario is V-Sync versus an external framerate limiter — specifically the RTSS (RivaTuner Statistics Server) Async limiter — and this is where the discussion needs to be handled carefully.

V-Sync has a bad reputation among many PC gamers, and not without reason. Traditional V-Sync can increase input latency, especially when the GPU is allowed to queue frames aggressively. It can also cause stuttering if the system cannot sustain the monitor's refresh rate. Dropping below a fixed V-Sync target can result in repeated frames and large jumps in frame persistence, which can feel terrible.

However, when a game can sustain the target refresh rate properly, V-Sync can also produce extremely clean display pacing. The reason is simple: V-Sync aligns frame presentation to the monitor's refresh cycle. When everything is working correctly, this can produce very even display times, which is why V-Sync can look visually smooth, albeit with a palpable trade-off in latency.

External framerate limiters, on the other hand, are often judged by how flat the frame time graph looks. Tools like RTSS can produce extremely consistent present pacing, which is why they are so popular among PC enthusiasts. In many cases, a good external limiter can be fantastic. But here is the important part: perfect-looking frame times do not automatically guarantee perfect-looking display times. If the framerate limiter's cadence is not aligned well with the monitor's fixed refresh behavior, especially with VRR disabled, then a game can appear smooth in terms of MsBetweenPresents while the display cadence is less clean in terms of MsBetweenDisplayChange. This does not mean RTSS or other FPS caps are bad. That would be the wrong conclusion. The correct conclusion is that a framerate limiter should not only be judged by how good the present time graph looks. It should also be judged by what happens at the display.

V-Sync

First, let us consider the frame time graph below with V-Sync enabled:

Then, the display times graph, also with V-Sync enabled:

As we can see from the above frame time graph, shown in blue, the MsBetweenPresents data looks noticeably spikier than expected and, if viewed in isolation, could incorrectly suggest that V-Sync is delivering an uneven or not-so-smooth visual experience. However, the display time graph, shown in green, tells a very different story. With MsBetweenDisplayChange enabled, frame delivery becomes much more consistent, with the largest deviations from the 8.33 ms target only landing in the 0.1–0.15 ms range. That kind of variance is far too small to be perceptible in actual gameplay, even to highly sensitive players. As such, this example clearly shows why display times can be a more accurate representation of perceived smoothness than traditional frame times in modern presentation scenarios.

External Framerate Limiter

For the RTSS Async limiter, let’s first view the frame time graph:

Then, the display time graph:

As for the RTSS Async framerate limiter, the frame time graph initially looks fairly convincing. There are still some spikes here and there, but overall consistency remains quite high, with most frame times staying close to the 8.33 ms target. However, the display time graph paints a very different picture. Compared to the V-Sync ON result, visible frame delivery is clearly less consistent, which lines up with the experience we had during testing. With the RTSS Async limiter used without V-Sync, the game exhibited noticeable judder and screen tearing, both of which were completely absent when V-Sync was enabled by itself. This is exactly why display times are so important: the frame time graph can make the limiter look reasonably well paced at the application/present level, but the display time graph more accurately reflects the uneven visual delivery that the player actually sees on the monitor.

Second Scenario: NVIDIA DLSS Frame Generation

The second scenario is NVIDIA DLSS Frame Generation, and this is arguably one of the clearest modern examples of why MsBetweenPresents is no longer enough on its own. With the latest version of DLSS Frame Generation on supported GeForce RTX 40/50 Series GPUs, frame pacing can happen after a game's Present() calls, which means that traditional present-based frame times may not accurately represent the cadence that is finally delivered to the monitor.

Let us first consider the following CapFrameX frame time graph with MsBetweenPresents:

As we can see from the above CapFrameX capture, testing DLSS Frame Generation with MsBetweenDisplayChange disabled makes the run look much worse than it actually feels. Since CapFrameX is relying on MsBetweenPresents here, the graph is effectively showing the application's present cadence rather than the final displayed cadence. The result is a messy-looking frame time plot that would normally suggest extremely poor frame pacing, with terrible 1% and 0.1% lows, even though this is not necessarily what the player is seeing on the display.

Now here’s that same previous CapFrameX capture, but with MsBetweenDisplayChange enabled in CapFrameX settings:

Once we run the exact same benchmark again with MsBetweenDisplayChange enabled in the CapFrameX capture settings, the picture changes completely. Display times now capture the actual cadence of visible frame changes, including the way DLSS Frame Generation output is being paced to the display. Instead of making DLSS FG look broken or poorly paced, the graph now shows frame delivery as it should be for a properly functioning frame generation presentation path. Judging the result only through present-based frame times can therefore make the experience look far worse on paper than it actually appears on the monitor. In this kind of presentation path, display times are not merely a secondary metric; they are the metric that best represents the final frame cadence being delivered to the player.

Why YouTube Videos Are Ill-Suited To This Kind Of Analysis

Since this topic is fundamentally about visible smoothness, it may sound obvious that video comparisons would be the best way to showcase it. Unfortunately, that is not always the case.

A normal YouTube video is not an ideal medium for demonstrating high-refresh-rate frame pacing differences. If the original gameplay was captured at 120+ FPS, but the final online video is shown at 60 FPS, then much of the temporal information we are trying to analyze has already been lost, resampled, or hidden.

As such, and for the purpose of this article, the previous graphs from the CapFrameX captures that we analyzed constitute the entire evidence of our claims.

The Pros And Cons Of Frame Times

At this point, it may sound like we are arguing that frame times are obsolete. That is absolutely not the case. Frame times remain incredibly useful, especially when you are trying to diagnose what is happening inside the game or your system. If a game has shader compilation stutters, asset streaming hitches, CPU-side stalls, GPU bottlenecks, or any other kind of inconsistent performance behavior, frame times can expose those issues very clearly.

Frame times are also the more intuitive metric for many forms of PC performance analysis. When we say that a game is running at 60 FPS, 120 FPS, or 240 FPS, we usually think in terms of how long the game takes to produce consecutive frames. This makes MsBetweenPresents extremely valuable for classic benchmarking and game engine-side performance analysis.

However, frame times have limitations. A frame being presented by a game does not guarantee that it was displayed cleanly, immediately, or at all. Frame times can also fail to fully capture the effects of VRR behavior, fixed-refresh scanout mismatch, external FPS limiter behavior, V-Sync pacing, tearing, and frame generation frame pacing modes.

In other words, frame times are excellent for understanding the production side of the pipeline. They are not always the best metric for judging the final display side of the pipeline.

The Pros And Cons Of Display Times

Display times, on the other hand, are much closer to what the player actually sees. In fact, if the display time graph is uneven, then the visible frame delivery is uneven. If it is clean, then the final displayed cadence is likely clean, assuming there are no other visual artifacts, latency issues, or capture limitations interfering with the interpretation.

This makes display times especially useful for judging perceived smoothness. They are also very helpful when comparing VRR behavior, frame generation pacing, V-Sync, and other FPS limiters’ impact on visual smoothness, etc.

However, display times are not perfect either. In effect, they do not always tell you why something went wrong inside the game engine. A display time spike can tell you that a frame was displayed for too long, but it may not immediately tell you whether the cause was the CPU, GPU, asset streaming, shader compilation, frame presentation mode, or something else entirely.

This is why the best analysis should not use one metric blindly. As such, frame times and display times should be seen as complementary.

So, Which Metric Should Tech Reviewers Use?

The answer to this question simply depends on the question being asked. If the goal is to determine whether the game engine is stuttering, whether the CPU is bottlenecking the GPU, whether shader compilation is causing hitches, or whether a graphics setting is overcommitting GPU/VRAM resources, then traditional frame times are still extremely useful. On the other hand, if the goal is to judge how smooth the game looks on the monitor, then display times are usually the more relevant metric. In our view, tech reviewers should show both whenever possible.

At the very least, performance analysis should be clear about which metric is being used. If a graph is based on MsBetweenPresents, it should be labeled as such. If percentile FPS numbers are based on MsBetweenDisplayChange, that should be made clear as well. This is especially important because two captures can tell different stories depending on the metric being used. A game may look clean in present times, but be uneven in display times. Another setup may look worse in present times than it actually feels on the display. Neither graph is necessarily “misleading”. They are simply measuring different stages of the frame rendering and presentation pipeline.

Final Words

For years, frame time graphs have been one of the best tools available for PC performance analysis, and that is still true today. They are far more useful than average FPS numbers alone, and they remain essential for diagnosing stuttering, hitching, hardware bottlenecks, and inconsistent game/engine behavior.

However, modern PC gaming has become more complicated than the old frame time graph can fully explain. VRR changes how the monitor follows the game; frame generation technologies often implement their own frame pacing mechanisms, and external framerate limiters can produce excellent present pacing while still interacting differently with the display. This is exactly why we strongly believe that display times deserve an important place in modern PC game performance analysis and benchmarking.

Follow Wccftech on Google to get more of our news coverage in your feeds.