Windows 11 frame time monitoring answers a question that FPS alone cannot: how evenly does a game deliver frames? Average FPS describes throughput, but a game at 90 FPS can feel jerky if a few frames arrive 80 ms late. Collecting frame times consistently is one of the clearest ways to distinguish a smooth cap from short-lived stutters. Capture a representative run, inspect the slowest frames, and compare against one controlled change. The aim is to find an actionable pattern, not to produce a single flattering average.
Convert average FPS to frame time and check slow frames
Frame time is conventionally shown in milliseconds. For a simple reciprocal approximation, 1000 ÷ FPS = milliseconds per frame: 60 FPS is about 16.67 ms, 120 FPS about 8.33 ms, and 30 FPS about 33.33 ms. This conversion is a rough relationship, not a way to reconstruct frame-time distribution from a single average FPS number.
A 60-FPS average with ten consecutive 50-ms frames may have obvious stutter even if later faster frames bring the mean back up. This is why monitoring a line graph and high-percentile slow frames matters more than quoting a peak-FPS screenshot.
Choose a capture method
Windows and GPU overlays can show FPS, GPU temperature and usage with little setup. For detailed frame timestamps and presentation data, Intel’s open-source PresentMon can capture event-traced frame measurements. Its documentation describes time columns in milliseconds and CSV output, with data grouped by process and presentation events. Be sure the tool captures the correct game executable rather than the launcher or browser.
Other vendor-specific monitoring programs may provide on-screen frame-time graphs; exact metrics and sampling intervals differ. Prefer raw CSV when making A/B comparisons, and label the game’s graphics API and frame-generation state. A graph based on generated frames is not necessarily the same as one tracking engine-rendered frames.
Build a reliable baseline
- Reboot if a major driver update is pending. Let the game compile shaders and finish download tasks before capturing.
- Record Windows build, driver, CPU/GPU, screen resolution and refresh, in-game resolution, graphics preset, frame limiter, VRR/VSync and power mode.
- Choose one repeatable gameplay route for a set duration, such as 90 seconds. Capture one warm-up and at least three comparable runs.
- Record median frame time, 95th- or 99th-percentile slow frame time, and maximum outliers. If your reporting tool provides FPS percentiles, be explicit about how it calculates them.
- Overlay notes for traversal, combat, menu opening or known asset loads; those markers help explain why a spike occurred.
- Change one option, repeat the same scene, and keep the result only if the improvement is reproducible.
Interpret common graph shapes
| Pattern | Plausible explanation | Next test |
|---|---|---|
| Nearly flat line at target | Stable frame cap and workload | Keep current settings |
| Repeated sharp isolated spikes | Background task, asset streaming, CPU scheduling | Correlate Task Manager and events |
| Gradual climb in frame time | Thermal/power limit or increasing scene complexity | Compare temperature and clocks |
| Two alternating frame-time levels | Frame pacing, sync or display cadence issue | Test VSync, VRR and FPS limit individually |
| Large initial stutters then smooth | Shader compilation/cache warming | Repeat identical route once |
A correlation does not identify a cause by itself. For example, temperature rises naturally under load, and a hot card may not be thermally throttling.
Do not confuse percentiles
A ‘1% low FPS’ metric is not automatically the reciprocal of the 99th-percentile individual frame time unless you know the tool’s definition and aggregation method. Some tools use time-weighted or sliding-window FPS calculations. Quote the specific metric names and tool version, especially when comparing two reviewers’ results.
Good reporting habits
Keep CSV files outside your game installation directory, remove personal paths before sharing logs, and annotate each test with a short note. Compare multiple runs using the same tool release. When a long frame aligns with an external network spike or game-server hitch, do not automatically classify it as a GPU problem.
Which PresentMon number should go in a stutter report?
For a Windows gaming trace, label MsBetweenPresents as an app-present interval and MsBetweenDisplayChange as visible display pacing; these may differ during frame generation or irregular frame delivery. PresentMon also documents hardware-accelerated GPU scheduling caveats for some GPU busy metrics and reduced precision for certain non-DirectX paths. Report the capture version, API, frame-generation state and whether the record concerns displayed frames or rendered frames. If a 99th-percentile frame time improves but the 99.9th-percentile gets worse, do not conclude the game is fully smooth: isolated hitches can remain. Keep raw CSV traces so a reader can reproduce your percentile math.
Build a small, comparable capture table from real runs
Capture three one-minute samples of the same game route with identical resolution, quality, FPS cap and hardware monitoring enabled. For each run record median frame time, 99th-percentile frame time, longest hitch and whether the GPU was power- or thermally limited. PresentMon’s displayed-frame intervals can expose pacing behavior that application Present counts alone may miss, especially when frame generation or dropped presents are present.
Read one capture row correctly: If a 60 FPS sequence maintained perfectly even presentation, its expected interval would be about 16.7 ms; a one-off 50 ms interval is a hitch even if the one-minute average FPS still looks high. These figures are arithmetic examples, not measurements from your PC. Use frame-time traces rather than calculating a 99th percentile from average FPS.
For PresentMon, label whether a reported value is the interval between app presents (MsBetweenPresents) or between display changes (MsBetweenDisplayChange). The latter may not be populated in every capture configuration. Export the actual time series, calculate the percentile over the captured frames, and repeat the same workload with warm-up and background tasks controlled.
A single 80 ms outlier may represent asset loading rather than a persistent GPU bottleneck; repeat the same location and check the timestamp against disk activity. Report the range across runs, not only the best run, and mention whether a percentile is computed from displayed frames, submitted frames or sampling software. Keep the raw CSV so future driver updates can be compared against the same baseline.
What to optimize first
If slow frames correlate with GPU saturation, reduce expensive graphics work or apply a more stable cap. If they correlate with storage loading, check drive health and capacity. If the graph stays flat while mouse input feels delayed, measure input or display latency separately. Frame-time monitoring provides a diagnosis framework, not a magic toggle.
