Frame rate is working as intended when the game or interactive application meets its declared performance target in representative scenes without unacceptable pacing, latency, visual defects, or quality loss. An average frames-per-second counter cannot establish that result by itself. Build a repeatable scenario matrix, capture frame times and presentation behavior, correlate CPU and GPU work, and compare the experience with the product's own target.
Define the target before collecting numbers
Record platform, hardware, operating system, driver, build, display connection, resolution, refresh rate, display mode, synchronization mode, graphics preset, power mode, thermal state, input method, and any dynamic-resolution or frame-generation setting. State the intended target for each supported mode. A quality mode and a performance mode may have different success criteria.
Choose representative scenarios: title screen, ordinary play, dense action, traversal, effects-heavy sequences, menus, cutscenes, loading transitions, multiplayer when authorized, and a sustained run long enough to expose thermal or memory behavior. Fix the route, save state, camera path, and duration so comparisons are meaningful. Do not compare different scenes and attribute the difference to one graphics setting.
Capture frame time and presentation evidence
Microsoft's Frame Pacing Sample describes CPU timing, GPU timing, swap-chain choices, scheduling, latency, presentation margin, and display cadence as related evidence. This matters because the same average rate can hide regular hitches or uneven delivery. Record frame-time distributions, long-frame counts, consecutive misses, and the locations of visible stutter.
Microsoft's PIX timing-capture guidance documents correlated CPU and GPU work plus presentation data such as frames per second and milliseconds between presents. Use the platform-appropriate capture tool and preserve the unedited capture when possible. Mark warm-up, loading, pauses, and background interruptions rather than blending them into ordinary play.
Presentation is not identical to submitting a frame. Microsoft's DXGI frame-statistics documentation distinguishes application Present calls from frames actually displayed by the monitor. When the platform exposes display statistics, compare produced frames, queued work, and displayed frames. Capture configuration changes alongside the measurements so a display-mode difference is not mistaken for an engine improvement.
Use a scenario matrix instead of one benchmark
Run each scenario several times after a consistent warm-up. Record median behavior plus a useful tail view, such as high-percentile frame time, without presenting a percentile as universal proof. Note run-to-run spread. A single unusually clean or poor pass should prompt another controlled run, not become the headline.
Include cold start and sustained play as separate cases. Test overlays, capture software, accessibility features, controller reconnects, window focus, and supported background transitions because they can change timing. For online play, separate rendering evidence from network latency and simulation behavior. Do not use other players or production servers for disruptive testing.
Diagnose the limiting stage
Compare main-thread, render-thread, GPU, queue, present, and display timing where tools permit. Change one reversible variable at a time: resolution, a single graphics feature, frame cap, synchronization mode, or representative workload. Repeat the identical scenario. If CPU time remains the limit, reducing a GPU-only effect may not explain improvement. If GPU time falls but presentation remains uneven, inspect pacing, synchronization, and display configuration.
Watch temperature, clock behavior, memory pressure, shader compilation, asset streaming, and background processes. Label compilation or first-use hitches separately from steady-state performance. Do not disable security, platform safeguards, or required accessibility features to produce a cleaner number.
Review the experience as well as the trace
Play back or observe the run for judder, tearing, input delay, animation irregularity, camera discomfort, and quality changes from dynamic systems. Ask whether the mode still delivers its promised resolution, effects, readability, and responsiveness. A stable rate achieved by illegible resolution or severe latency may fail the intended experience even if the counter is green.
Record expected and observed results for each supported configuration. Link anomalies to timestamps and captures, assign an owner, and rerun after correction. The frame-rate system passes when representative scenarios meet the declared target with consistent pacing and acceptable responsiveness, and when known limitations are documented rather than hidden behind an average.
Sources
- Frame Pacing Sample — Microsoft Learn, Sept. 14, 2026
- Profile the CPU and GPU with timing captures — Microsoft Learn
- DXGI_FRAME_STATISTICS structure — Microsoft