Charts · 05

How a keypress becomes a pixel

Between your finger and the letter appearing there are twelve hops through the keyboard, the operating system, the browser, the renderer and the display. This draws each one to its share of the time. The knobs change the hardware; the page-work knob is the only part an app controls, and it is rarely the biggest bar.

Keyboard polling
Display refresh
Page work
Panel

44 ms from finger to glass with these settings. The display alone is 21 ms of that.

Keyboard
Operating system
Browser
Rendering
Display

Hover a hop

Twelve hops, drawn to their share of the total. Change the knobs and watch which ones move. Notice that the code you write is two of the twelve, and the display is three.

  1. 1 Switch travel and debounce 5.0 ms
  2. 2 Matrix scan 1.0 ms
  3. 3 USB polling 4.0 ms
  4. 4 HID stack and event queue 1.0 ms
  5. 5 Delivery to the app 1.0 ms
  6. 6 Event dispatch 1.0 ms
  7. 7 JavaScript handlers 6.0 ms
  8. 8 Style and layout 2.0 ms
  9. 9 Paint and composite 2.0 ms
  10. 10 Waiting for the next frame 8.3 ms
  11. 11 Scan-out 8.3 ms
  12. 12 Pixel response 4.0 ms

Notes

Values are typical figures for a modern laptop, not measurements of any one machine: a mechanical switch and its firmware debounce at about 5 ms; USB HID polling at 125 Hz by default (an 8 ms interval, so a 4 ms average wait) or 1000 Hz on gaming hardware; the compositor waiting on average half a refresh interval for vsync and the panel taking another half to scan the frame out; liquid crystal response between 1 ms (OLED, near zero) and 12 ms or more (older LCDs). Browser stages follow the pipeline in Chromium’s rendering documentation: input dispatch, script, style, layout, paint, composite.

Sources: Dan Luu, Computer latency 1977 to 2017 (measured end-to-end keyboard-to-screen latencies of 30 ms on an Apple IIe and 60 to 170 ms on modern machines); Chromium, Life of a Pixel and RenderingNG; the USB HID specification; Microsoft, Keyboard latency; RTINGS input lag methodology.