A frame-rate option can live in the game, console mode, graphics driver, operating system, display, launcher, or external utility. Those layers differ in portability and ownership. A setting that works on one PC may not follow the save file, and a driver profile may disappear after a clean install. Compare options by locating the controlling layer and reproducing the result on a second supported setup.
Separate the available control layers
List the game's internal frame-rate target, quality or performance modes, vertical synchronization, dynamic resolution, frame generation, platform-level display mode, driver cap, monitor refresh and adaptive-sync settings, and any external limiter. Record which setting wins when layers conflict.
An in-game option is usually closest to the game's simulation and render design, but its persistence may depend on local configuration or cloud synchronization. A console performance mode can be consistent on supported hardware but limited to platform-approved choices. A driver cap may apply per game or globally but remains tied to the driver ecosystem. An external tool may offer detail while adding another dependency and support risk.
Define portability precisely
Test four kinds of portability: moving to another device with the same account, moving to different supported hardware, reinstalling the operating system or driver, and changing storefront or platform. Record whether the setting follows automatically, can be exported, must be recreated, or is unavailable.
Do not describe a copied configuration file as portable until it can be restored on a clean supported setup. Preserve file format, version, hardware assumptions, path, account dependency, and a safe rollback. Avoid copying machine-specific or unsupported tuning values blindly.
Identify who controls the option
For each layer, record the product owner, administrator, account, update authority, configuration location, and support source. Determine whether the player, game developer, platform, driver vendor, or display controls defaults and updates. Note whether an update can reset the choice or make it incompatible.
Microsoft's Dynamic Latency Input documentation separates controller reporting, game input reads, simulation, rendering, and output timing. A frame-rate control at one layer does not own every stage of the input-to-display path.
Compare measurements at the same boundary
Create a repeatable scene, settings profile, warm-up, run length, and measurement method. Capture average FPS, frame-time distribution, visible stutter, CPU and GPU load, resolution behavior, power, temperature, input response, image tearing, and stability where available. Use several runs and retain the raw evidence.
NVIDIA's Reflex overview distinguishes frame rate from end-to-end system latency and describes measurement paths that may require supported games or hardware. Do not convert FPS into a claimed click-to-pixel latency or treat an unavailable measurement as zero.
Test conflicts and recovery
Combine the in-game option with the platform, driver, and display settings you expect users to have. Check global versus per-game profiles, foreground and background behavior, windowed and full-screen paths, display reconnect, sleep, driver update, game patch, crash recovery, and unsupported refresh requests.
Change only one layer at a time. Preserve the known-good state and restore it after each test. If two limiters interact, record the observed result without assuming which one controlled the final cadence.
Include accessibility and user choice
Verify that every performance mode keeps text readable, menus responsive, settings reachable, motion controls available, and subtitles and assistive cues correctly timed. Some players may prefer a stable lower target to an unstable higher average, while others may require a more responsive mode. Present tradeoffs without declaring one universal best setting.
Check that the choice is described in plain language and can be changed without an inaccessible confirmation timer. Retain motion blur, camera shake, field of view, and other comfort settings across mode changes as designed.
Score ownership and exit risk
Compare options for supported hardware range, account dependence, export and restore, cross-device behavior, update resilience, measurement transparency, stability, accessibility, image quality, power, support life, rollback, and administrative control. Penalize undocumented behavior and abandoned utilities rather than rewarding extra switches.
The preferred option is the smallest supported control layer that consistently produces the required experience and can be restored by the rightful owner. Keep a configuration map, test matrix, raw results, version record, known conflicts, and rollback steps. Portability is proven by a successful move, and ownership is proven by durable authorized control, not by the fact that a setting is visible today.
Sources
- Dynamic Latency Input — Microsoft Learn
- NVIDIA Reflex Low Latency Platform — NVIDIA