A frame-rate change is only useful when you can tell what changed and reproduce the comparison. Keep the exact game or application build, scene, hardware, driver, display mode, graphics settings, capture method, run conditions, and raw output. An average frames-per-second number without this context cannot show whether the change improved consistency, latency, image quality, or only one favorable test run.
Define the question before collecting numbers
State whether the change is intended to raise throughput, reduce stutter, lower input-to-display latency, stabilize a frame cap, reduce power use, or preserve visual quality. Choose one primary outcome and a small set of guardrails. For example, a frame cap might target steadier frame times while keeping image quality and responsiveness acceptable.
Write the expected direction before testing. Do not change resolution, upscaling mode, graphics preset, refresh behavior, and driver options at the same time unless the bundle is the object being evaluated. One-factor changes are easier to interpret; a planned bundle still needs a complete settings snapshot.
Record the test environment
Capture the CPU, GPU, memory, operating-system build, graphics driver, display model, resolution, refresh rate, connection type, power plan, thermal state, background applications, game build, save location, and exact graphics menu. Note vertical synchronization, variable refresh, frame generation, dynamic resolution, upscaling, frame limit, and window mode.
Use screenshots for menus and a text record for searchable values. Save the date, room or device conditions that may affect thermals, and whether shaders were compiling. Restart conditions should be consistent. If the system receives an update between runs, treat it as a new test environment rather than merging results silently.
Preserve raw frame-time evidence
The NVIDIA FrameView page describes measuring frame rates and frame times and writing detailed metrics to a log. Keep the raw log, summary, tool version, overlay configuration, start and stop points, and run length. Record at least several comparable runs rather than selecting the best one.
Average FPS is not the whole experience. Preserve frame-time distributions or low-percentile measures supported by the tool, visible stutter notes, loading transitions, and any invalid runs. Mark exclusions with a reason before looking at the final comparison. Do not mix a built-in benchmark with free gameplay as if they were the same workload.
Keep capture configuration and overhead visible
Microsoft's PIX timing-capture guidance explains that timing captures can combine CPU and GPU information and that additional capture options may add overhead. If a profiler is used, preserve its mode, selected data providers, sampling options, buffer behavior, instrumentation, and symbol configuration. Compare like with like.
Profiling evidence can help explain why a frame changed, but it should not be confused with the player-facing benchmark. Keep diagnostic captures and performance runs in separate folders with clear names. A deep capture may be excellent for root-cause analysis while being unsuitable for a headline FPS comparison.
Document visual and interaction tradeoffs
At the same camera position and lighting, capture lossless images or short local clips when permitted. Note texture detail, shadows, reflections, motion artifacts, tearing, judder, and interface clarity. If frame generation or upscaling is enabled, label it prominently instead of comparing generated output with native rendering without disclosure.
Record controller or mouse settings and a short input-response check. Avoid claiming an end-to-end latency improvement from FPS alone; a frame-rate tool may measure only part of the path. Keep the exact metric definition supplied by the tool.
Finish with a reversible decision record
Store the before and after settings, raw logs, summaries, test script, run notes, screenshots, anomalies, decision, approver, and rollback instructions. Hash or version important files when the platform permits it. A concise table should show every run rather than only the chosen result.
After applying the change, recheck the original scene and one different workload. Roll back if the target improves only by breaking a guardrail such as visual quality, stability, temperature, or accessibility. Good evidence turns “it feels faster” into a bounded claim: on this system, with this build and test, these settings produced these measured results and can be restored if conditions change.
Sources
- Profile the CPU and GPU with timing captures — Microsoft Learn
- FrameView App — NVIDIA