Controller Input Latency: Tracing the Path From Button to Pixel

“Input lag” gets treated as one number, but it’s really the sum of several independent delays stacked in sequence — each one small, each one real, and each one an emulator setup has at least some ability to influence.

The full chain, stage by stage

button press
   │
   ▼  controller polling interval
   │  (how often the controller reports its state — USB polls
   │   at a fixed rate; wireless/Bluetooth adds its own delay)
   ▼  OS input stack
   │  (buffering and processing before an application ever sees the event)
   ▼  emulator core: this frame or next?
   │  (if the poll lands after this frame's input read, it waits
   │   a full frame before it's even seen)
   ▼  core simulation
   │  (the emulated game logic processes the input)
   ▼  video output buffering
   │  (double or triple buffering delays a completed frame's
   │   actual display by one or more additional frames)
   ▼  display panel response + processing
      (pixel response time, plus any post-processing the
       display itself applies — upscaling, motion smoothing)
   │
   ▼
visible result on screen

Every stage adds real, measurable time, and the stages compound — a setup with several small delays stacked back to back can add up to something clearly noticeable, even if no single stage looks bad in isolation.

The delay is also phase dependent. A controller event that arrives just before the game’s polling point can be used immediately, while the same physical event a fraction of a millisecond later waits until the next poll. Display scanout has similar phase: pixels near the bottom of the screen are illuminated later than pixels near the top. One “input lag” number without a distribution or measurement position is incomplete.

The game itself can intentionally wait

Many games do not turn a sampled input into visible motion on the next possible video frame. Animation rules, input filtering, command buffers, physics updates, and rendering order can add one or more frames of internal latency on original hardware. A fair emulator comparison first measures that native behavior rather than assuming all delay belongs to USB, the frontend, or the display.

Some consoles latch controller state at a software-selected time. Others expose serial interfaces that the game polls. Arcade boards and rhythm games can use their own scan and debounce logic. Accurate emulation preserves when software can observe the device, even if polling more often on the host would feel faster.

Where emulation adds delay a real console didn’t have

A real, original console has most of this chain too — controller polling and display response time are physical realities regardless of platform — but emulation introduces its own additional links: the host OS’s input stack sits between the controller and the emulator core in a way the original hardware’s dedicated controller port never did, and video output typically passes through an extra buffering/compositing layer (the host OS’s window manager or display server) that the console’s direct video-out signal path didn’t have to cross.

Emulation can also remove delay present in a modern capture or conversion chain. An original console routed through a scaling box, capture device, television processing mode, and wireless controller is not automatically lower latency than a carefully configured emulator. Compare complete, documented paths rather than “hardware” and “software” labels.

Controller transport and host polling

USB devices advertise polling intervals and may update their internal state at a different cadence from USB transfers. Bluetooth and proprietary wireless links add scheduling, retransmission, and controller-side scanning behavior. A nominal high polling rate does not prove the buttons themselves are sampled or delivered at that rate.

The operating system timestamps or queues reports, and the frontend chooses when to read them. Libretro distinguishes input polling behavior around retro_run; a core can request early, normal, or late polling semantics. Late polling can shorten the interval between host input sampling and guest execution, but only when the core’s behavior and frontend implementation support it safely.

Avoid unsupported “overclocking” utilities or unsigned drivers merely to chase a smaller interval. Measure dropped reports, CPU overhead, wireless stability, and multi-controller behavior. A stable wired controller at a known cadence can outperform a higher advertised rate with irregular delivery.

Run-ahead: borrowing the rollback-netcode trick, applied locally

Run-ahead targets internal game latency by using fast save states and additional emulation. In RetroArch’s model, the frontend saves the current state, advances the core by a configured number of frames so it can display a later result, and restores or maintains the authoritative timeline through its run-ahead implementation. It is related conceptually to rollback because both depend on deterministic re-simulation, but it is not network prediction waiting for a future local button press.

Set the number of run-ahead frames from measured native internal delay. Too much can show animation or game state earlier than original hardware and can cause visible discontinuities. Cores with incomplete save states, nondeterministic state, threaded subsystems, disc timing, or expensive serialization may glitch or perform worse. Second-instance run-ahead can reduce some audio and state side effects at additional CPU and memory cost.

Run-ahead cannot remove the physical controller interval, display scanout, or panel response after the emulated frame exists. It also needs performance headroom: simulating multiple frames inside one real frame deadline is useful only if it does not create misses and stutter.

Video presentation is often the largest adjustable queue

The emulator renders through a graphics API, optional shader passes, driver queues, an operating-system compositor, and a swapchain. FIFO V-sync prevents tearing but can queue completed images. Mailbox or low-latency modes may reduce stale frames, while immediate presentation can tear. Names such as “double” and “triple buffering” do not define identical behavior across APIs.

Frame delay or just-in-time rendering intentionally postpones emulation work until nearer the presentation deadline, reducing how long a completed frame waits. This needs stable performance; an aggressive value turns small CPU or GPU variations into missed refreshes. Precompile shaders and test demanding scenes before deciding the setting is safe.

On the display, disable motion interpolation and unnecessary image processing through an appropriate game or low-latency mode. Pixel response time is not the same as input lag: processing and scanout determine when a transition begins, while response measurements describe how the pixel approaches its target. Variable-refresh displays can reduce cadence queues but do not make late emulator frames timely.

What’s actually adjustable in practice

Of the whole chain, an emulator setup typically has direct control over: which buffering mode the video output uses (single/double/triple — fewer buffers means less inherent delay, at higher risk of visible tearing without it), whether run-ahead is enabled (and how many frames deep), and audio/video sync settings that can otherwise silently add a frame or more of latency to keep audio and video aligned. Controller polling rate and display response time are hardware properties outside the emulator’s control entirely — which is why serious low-latency setups pay attention to both the software configuration and the physical controller and display being used, since neither one alone determines the final result.

Measure button to photon, then isolate stages

A high-speed camera can record a controller LED wired to the button and the relevant screen region in the same shot. Count frames from electrical activation to first visible change, repeat many times at different phases, and report the camera rate and screen position. Purpose-built latency sensors and oscilloscopes can improve precision, but they still need a trustworthy trigger tied to the actual input event.

Software overlays can measure emulator frame time or queue depth, not the whole physical path. Controller polling tools characterize report delivery, while display testers characterize presentation and pixel onset. Combine measurements instead of subtracting unrelated best-case marketing numbers.

Use a game or test program with a known immediate visual response, disable random animation, and compare the same software region and video mode. Report median, minimum, maximum, and sample count. A single unusually fast result usually captured favorable polling and scanout phases.

Optimize without falsifying the machine

Start from full-speed, correctly paced emulation. Enable late polling, reduce stable queues, and select a low-latency display path one change at a time. Then consider run-ahead only for measured internal frames and validate audio, save states, deterministic replay, and heavy scenes. Keep an accuracy-oriented profile when a latency option changes original timing.

The target is not zero milliseconds. It is a reproducible path whose added host latency is understood and whose optional reductions do not make the emulated game behave earlier or differently than intended.

Related:

Sources: