Input-lag handoff notes should make a performance result reproducible. Record the full path from input device to displayed frame, the exact measurement point, the tested settings, and the evidence behind the conclusion. A single number without its method can mislead because controller, game, CPU, GPU, frame queue, display, and network can contribute different delays.
Define the system under test
List the computer or console, operating-system build, game and version, input device and connection, display model and connection, native resolution, selected refresh rate, graphics processor and driver, frame-rate cap, synchronization features, display mode, and any streaming service or network path. Record whether the result concerns local input, PC latency, display latency, or end-to-end response.
State the measurement boundary
Name the tool, version, metric, units, sample duration, warm-up, run count, and start and end points. NVIDIA's FrameView guide defines PC latency as the time from the PC receiving input until a frame is sent to the display and explicitly excludes mouse and monitor display latency. If that is the metric, do not label it end-to-end latency. Keep screenshots or exported results with timestamps and configuration identifiers.
Preserve a baseline
Measure a stable known-good configuration before changing settings. Record average and representative variation across repeated runs rather than selecting the best sample. Note scene, save point, match type, server region, background workload, power mode, and thermal state. For cloud gaming, also record network connection, latency, loss, and service region, but keep network delay separate from local rendering settings.
Document refresh and presentation settings
Record the Windows advanced-display refresh rate and whether variable or dynamic refresh features are enabled. Microsoft states that available refresh rates depend on the display and that some selections can change resolution. It also documents windowed-game optimizations for compatible DirectX 10 and 11 games as a move to flip-model presentation that can reduce frame latency. Treat these as testable configuration changes, not universal guarantees for every game.
Write a controlled test procedure
Use the same scene, input sequence, resolution, graphics preset, display mode, run length, and recording method. Change one setting at a time, restart the game when required, and record both the configuration and result. Include a control run after the experiment to detect drift. Do not mix local play and streamed play in one comparison.
Include subjective reports carefully
Record who noticed the delay, the exact task, and whether the report was made blind to the setting when practical. Keep subjective feel separate from measured evidence. A setting can feel smoother because of motion clarity while the chosen metric changes little; the notes should preserve both observations without turning either into proof of the other.
Add rollback and ownership
List the last known-good values and the person authorized to change drivers, firmware, display settings, game configuration, or network equipment. Save configuration files only where licensing and privacy rules permit. Record how to reverse each tested change and which changes require a restart. Do not update firmware during a handoff test unless it is separately approved and recoverable.
Verify the incoming operator
Have the new owner reproduce one baseline run, identify the measurement boundary, change and restore one harmless setting, and explain the known limitations. Record the result and unresolved variance. The handoff is complete when another person can reproduce the method and distinguish a measured improvement from an untested explanation.
Sources
- Change the refresh rate on your monitor in Windows — Microsoft Support
- Optimizations for windowed games in Windows 11 — Microsoft Support
- FrameView 1.4 User Guide — NVIDIA