A realistic frame rate maintenance schedule uses a frozen benchmark and repeats it after performance-relevant changes. Capture frame times and frame rate on defined scenes, devices, settings, power states, and display modes; compare the results with an approved baseline; investigate regressions; and update the baseline only after review. Add lighter recurring tests between deeper hardware-matrix runs.
Define the performance contract
Choose the player-facing target and the conditions under which it applies: resolution, quality preset, device class, power mode, thermal state, game mode, display mode, and scene. Record frame time as well as average frames per second because a short hitch can be hidden by a healthy average. Apple explains that hitching occurs when a frame takes too long and notes that whole-level frame-rate recordings and frame-time measurements help reveal performance behavior. See Apple's graphics performance guidance.
Keep frame rate, frame pacing, display refresh rate, and input latency as separate measures. Variable-refresh displays can change presentation behavior, so the test record should say whether variable refresh, synchronization, a frame limiter, or tearing was enabled. Microsoft's variable refresh rate guidance documents the DXGI support checks and presentation flags used by Windows applications.
Use event-driven and recurring tests
Run the representative benchmark after changes to rendering code, shaders, assets, effects, simulation load, drivers, operating systems, graphics settings, upscalers, frame generation, device firmware, or build configuration. Test the changed scene plus one stable control scene so a measurement-tool or environment change is easier to detect.
A practical starting cadence is an automated smoke test on important builds, a weekly representative-scene comparison, and a monthly or release-candidate hardware matrix. These intervals are examples, not standards. Increase coverage for active optimization work or after a regression; reduce it only when the product and test environment are stable and monitored.
Preserve comparable evidence
For every run, store the build identifier, device, CPU and GPU, driver, operating system, display mode, resolution, settings, power and thermal notes, scene route, warm-up procedure, capture duration, and raw output. NVIDIA's FrameView description says its benchmark collects more than 40 metrics and saves logs, and it provides summary data that references benchmark logs. See NVIDIA FrameView. The tool is one option; the essential practice is to retain raw, labeled evidence.
Compare median and tail behavior, not just a single average. Review one-percent-low results or frame-time percentiles if the capture tool provides them, and inspect the time series around hitches. Repeat enough runs to identify unstable results. Do not merge different scenes, settings, or devices into one number that obscures a regression.
Control baseline changes
A baseline should change only when the team knowingly changes the performance contract, hardware tier, test route, or measurement method. Record who approved the change and preserve the old baseline. If a new driver or operating-system update changes results, keep both environment records instead of overwriting history.
A useful maintenance report ends with a decision: pass, investigated variance, accepted regression with reason, or failed gate with an owner. That makes frame-rate testing part of release control rather than a collection of unlabeled screenshots.
Sources
- Improving Your Game's Graphics Performance and Settings — Apple Developer
- Variable Refresh Rate Displays — Microsoft Learn
- FrameView Performance and Power Benchmarking App — NVIDIA