What This Calculator Adds Up
Click-to-photon latency describes the time from a physical mouse or controller action to the corresponding visible change on a display. There is no reliable way to discover your complete system latency from browser specifications alone. This calculator creates an illustrative timing model from the component values and frame/display assumptions that you choose. It is not a latency measurement, manufacturer benchmark, or guaranteed real-world prediction.
Peripheral processing, input sampling, game logic, render work, queueing, presentation, scanout, display processing, and pixel transition can each matter. Some CPU and GPU work may overlap; a deliberately additive breakdown is useful for exploring scenarios but is not a physically exact trace of every engine.
How to Use This Calculator
- Enter your game's approximate FPS and the display refresh rate in Hz. The calculator shows their intervals (1000 / value), not a claim that each interval is automatically added as lag.
- Enter the number of additional queued frames you want to model. Use zero when unknown unless you have relevant frame-queue evidence; each modeled queued frame adds one game frame interval in this simplified scenario.
- Choose whether to include a variable input-to-frame phase window and a potential present/synchronization wait window. Either may range from 0 to one relevant interval in this illustration; the exact behavior depends on the game and display pipeline.
- Choose the screen location to model: top, middle, or bottom. A simplified top-to-bottom scanout gives that position a fraction of one display refresh period.
- Enter separate assumptions for peripheral, game/CPU, GPU render, compositor, display processing, and pixel transition. Do not enter a monitor's measured total display input lag as processing latency if that measurement already includes scanout or response timing.
- Read the low, midpoint, and high illustrative scenarios. They are conditional on the chosen timing windows and ± variation, not measurement error bounds or confidence intervals.
- Save the current model as Setup A, change your inputs to compare Setup B, then Copy Model Summary or Download JSON. No settings are changed on your PC.
How the Calculation Works
Game frame interval (ms) = 1000 ÷ game FPS and display refresh interval (ms) = 1000 ÷ display Hz.
The model midpoint adds the entered six component durations, any assumed queued-frame delay, a chosen scanout fraction, and half of each enabled 0-to-one-interval wait window. For the low scenario, window waits are zero and the six component durations are reduced by the selected percentage. For the high scenario, enabled windows use their full interval and those component durations increase by the percentage.
The result is a model of ten separately labeled terms, not a universal latency formula. In real pipelines, CPU and GPU stages overlap, frame time does not uniquely determine time from a specific click to a specific displayed update, and synchronization and scanout are highly implementation-dependent.
Understanding Each Stage
| Stage | What the model represents |
|---|---|
| Peripheral input | Delay from a physical action to an input event reaching the application. |
| Input-to-frame phase | Illustrative wait until the next useful game update, not the GPU render duration. |
| Game/CPU | CPU-side processing of an update; can overlap with GPU activity. |
| Queued work | Chosen number of extra queued frames times the game frame interval. |
| GPU render and compositor | Illustrative work to produce and prepare a frame for presentation. |
| Potential present wait | Assumed wait to a display presentation opportunity; not always present. |
| Display scanout | Fractional top-to-bottom scanout to your chosen pixel position. |
| Display processing and pixel transition | Separate assumptions for the panel's signal handling and visual change; beware double counting review data. |
Benefits and Practical Uses
- Explore why frame rate, refresh rate, frame queue, and screen position are not interchangeable.
- See how a hypothetical queue or synchronization wait changes the modeled latency range.
- Compare two internally consistent assumptions before deciding which component deserves a closer hardware measurement.
Common Mistakes to Avoid
- Treating 1000/FPS as measured lag. It is a frame period, not end-to-end input delay.
- Double counting display lag. A monitor review may measure an end-to-end display-path delay instead of pure processing time; scanout and pixel response may already be included.
- Assuming independent sequential stages. Game/CPU, queued work, GPU render, and presentation can overlap or interact, so their simple sum is not necessarily an observed timing.
- Reading “low/high” as a statistical confidence interval. The range is set by selected scenario rules, not a sampling distribution or real measurements.
Frequently Asked Questions
What's a "good" total input lag for competitive gaming?
There is no universal threshold for all games and players. Real click-to-photon testing needs specialized hardware or properly instrumented game telemetry. Compare measured results under the same test setup instead of treating this model's midpoint as a gaming-grade score.
Does V-Sync affect this calculation?
Yes, V-Sync and presentation scheduling can affect queueing and waiting. The optional present-wait window lets you explore up to one assumed refresh interval, but it is not a measurement or a complete simulation of V-Sync, VRR, frame caps or low-latency modes.
Where do I find my monitor's processing lag and pixel response numbers?
Independent reviews with test hardware can help, but check what each number includes. “Input lag” for a measured monitor may already include scanout and visual response, while a gray-to-gray pixel-response specification describes only one transition and is not necessarily additive as a separate fixed constant.
Where Input Lag Actually Accumulates in a Setup
End-to-end input latency connects the input device, game/PC pipeline, and display. Input may arrive just before or after a game samples it. CPU work can be overlapped with GPU rendering. Queued frames and presentation synchronization can add delay, while scanout time depends on the pixel's location and the scan pattern. Panel processing and response change with display mode and transitions. This is why the tool shows each part with its assumptions rather than claiming that a single precise number applies to your system.
Conclusion
Use this calculator as a transparent what-if model for comparing FPS, refresh rate, queueing and assumed hardware durations. It never reads actual click-to-photon delay. For dependable latency numbers, look for instrumented game tests or external input-to-display measurement equipment. If you want to explore possible CPU/GPU limits rather than latency, the Bottleneck Calculator is a separate estimation tool.