You cannot transfer frame rate itself to a new device, tool, or owner. Transfer a reproducible performance baseline: game and build, scene or save, resolution, quality preset, render scale, frame cap, VSync and variable-refresh settings, hardware, display, operating system, driver, capture tool and version, warm-up, run duration, raw results, and acceptance criteria. Then rerun the same workload and compare like with like.
Freeze the benchmark definition
Choose a repeatable scene, route, replay, or scripted workload. Record the start state, camera path, duration, number of runs, warm-up, background tasks, network state when relevant, and whether shader compilation or asset streaming is included. Save the configuration and build identifier with the results.
Distinguish rendered frame rate from display refresh rate. Microsoft's display guidance describes matching refresh rate to video frame rate in relevant playback cases, illustrating that the two values are related but not interchangeable. Record both so a new display mode does not look like a game performance change.
Preserve timing controls
Document the frame cap, VSync, presentation mode, variable-refresh range, window mode, resolution, dynamic resolution, upscaling, frame generation, and latency options. Microsoft's variable refresh rate documentation notes that VRR behavior requires tearing support and that disabling VSync does not necessarily uncap frame rate because other timing mechanisms may still throttle presentation.
Take screenshots or export configuration where possible, but also write the values in a neutral text record. A vendor profile, registry entry, or application preset may not survive a new device, account, driver, or tool.
Transfer raw evidence, not one average
Keep per-frame or per-interval data when the tool permits it, plus average frame rate, frame times, run duration, and percentile or low-frame metrics. NVIDIA's FrameView description explains that the tool can report rendered and displayed frame rates, frame times, and percentiles; it also uses the relationship between a high frame-time percentile and the average to discuss consistency.
Record the capture tool, version, command or UI settings, output units, and treatment of loading screens, menus, pauses, and outliers. Different tools or percentile definitions can produce different numbers from the same run. Never merge results without documenting the method.
Reproduce on the new system
Install the approved build and capture tool, apply the recorded settings, verify the display mode, restart when required, warm the workload, and run the planned repetitions. Check logs for tool errors or missing samples. Compare both central performance and frame-time consistency.
If hardware differs, treat the new result as a comparison, not a continuation of the same machine. Explain changes in CPU, GPU, memory, thermal state, power profile, display, driver, OS, and background load. Exact frame-rate numbers are workload- and hardware-specific.
Hand the baseline to a new owner
Deliver the benchmark instructions, configuration, build or commit identifier, test assets, raw captures, summarized results, known limitations, expected tolerance, and owner of the next run. Use invented or licensed test assets where rights are unclear, and do not include private account credentials in a save or capture.
A successful transfer is demonstrated when another person can repeat the test, explain any material difference, and recover the raw evidence. The practical tradeoff is that tighter environmental control improves comparability but may represent ordinary player conditions less well, so keep both a controlled baseline and clearly labeled field measurements when each is useful.
Sources
- Variable Refresh Rate Displays — Microsoft Learn
- Display — Microsoft Learn
- FrameView Performance and Power Benchmarking App — NVIDIA