A useful input-lag change record must let another person recreate the test and determine whether the change helped. Keep the definition of latency, the complete test conditions, raw observations, the exact change, and a comparable before-and-after result. A single number or a note that the game feels faster is not enough.
Define the latency you measured
Start by naming the interval. Microsoft distinguishes input latency from broader end-to-end latency: input latency can mean the time from a button press to the game reading it, while the visible experience also includes game processing, rendering, transport, and display response. Its Dynamic Latency Input documentation describes the input portion, and its streaming latency reference warns that a streaming measurement does not represent the full button-to-pixel path.
Record whether the result covers controller-to-game, render latency, network-added latency, display response, or full click-to-visible-response latency. Keep the unit, the measurement tool and version, and the event used to start and stop the timer. If the tool reports an average, preserve the individual samples or distribution when available rather than copying only the average.
Freeze the test conditions
Capture the system before changing it: device and model, controller or mouse, wired or wireless connection, display, resolution, refresh rate, display mode, frame cap, synchronization settings, game build, operating system, graphics driver, and relevant accessibility or power settings. For streamed play, also note client device, network path, connection type, service region, and whether the session was local or remote.
Use the same scene and action for both runs. Keep a short script that states where the character or cursor starts, what input is made, how many repetitions are collected, and what warm-up is performed. Save screenshots or exported settings when they are useful, but do not treat an image as a substitute for searchable values.
Hardware measurement can provide a more direct end-to-end result. NVIDIA describes its Latency and Display Analysis Tool as a cross-platform hardware analyzer that measures motion-to-photon or click-to-visible-response latency with a luminance sensor. If a camera, sensor, or another analyzer is used, keep its model, sampling or frame rate, sensor position, calibration check, and the raw capture.
Preserve the change itself
Write down the exact setting, component, cable, driver, firmware, game option, network route, or code version that changed. Include the old and new values, the time, the operator, and a reason. Change one factor at a time when practical. If several factors must change together, label the result as a package test and avoid crediting one component without a separate comparison.
Keep proof that the intended setting actually took effect. A menu selection can fail to apply after a restart, and a display can silently use a different mode. Reopen the settings, capture the active state, and note any restart or reconnection. For development work, retain the build identifier and configuration file or commit reference, not private credentials or unrelated logs.
Keep raw trials and a fair comparison
Run enough repeated trials to expose variation. Preserve every valid reading, the rule for excluding a trial, the number of excluded results, and the reason. Compare like with like. Do not compare one display mode at a stable frame rate against another mode during a heavy scene and call the difference an input setting result.
Summarize the median or another stated statistic only after saving the raw data. Record uncertainty and practical limits. Microsoft notes that streaming metrics can omit engine, display, Bluetooth, and other parts of the path, so a measured improvement in one segment does not prove the whole experience improved by the same amount.
Close with validation and rollback
Repeat the preferred configuration after a reboot and during ordinary play. Check responsiveness, visual artifacts, stability, battery or power impact, and accessibility. Invite a second tester when the change depends on perception, but label subjective notes separately from measured timings.
Finish the record with the decision, approved configuration, known tradeoffs, and rollback steps. Keep a final baseline that can be rerun after a game, driver, firmware, display, or network change. The strongest evidence is a reproducible packet: definition, conditions, raw trials, exact change, comparable result, limitations, and a verified way back.
Sources
- Dynamic Latency Input — Microsoft Learn
- XGameStreamingGetStreamAddedLatency — Microsoft Learn
- NVIDIA Latency and Display Analysis Tool — NVIDIA Developer