INPUT RATE

The sampling rate, or report rate, is how many times per second the touch digitizer measures your finger's position. It is set by the touch controller firmware. The digitizer and the display panel are separate parts, so a 120 Hz screen can ship with a 60 Hz or 100 Hz digitizer.

When the sampling rate divides evenly into the refresh rate, repeated frames land in a regular pattern the eye reads as slight softness. When it does not divide evenly, the repeats drift, producing a beat frequency equal to the difference between the two rates. A 100 Hz digitizer under a 120 Hz panel beats at 20 Hz, which reads as periodic hitching rather than uniform softness.

While your finger is down, scroll position follows your finger and is capped by the digitizer's sampling rate. After you release, the browser runs a momentum animation on the compositor thread, which can produce a new position every frame. Measuring the two separately shows whether stutter comes from your hardware or from the page.

The momentum animation already targets your display refresh rate. It falls short when the page forces scrolling onto the main thread, usually through non-passive touch listeners, heavy paint work, or fixed backgrounds. Those are page problems rather than settings, so a heavy site coasts worse than a plain one on identical hardware.

They are two different event streams from the same device. Cursor movement produces pointer events, which the browser can batch so several raw readings arrive behind one frame. Scrolling produces wheel events, which are delivered separately. A trackpad may also genuinely report at a different rate for a cursor gesture than for a two-finger scroll. The two figures are labelled separately for that reason, and a difference between them is real, not an error.

A frame the display drew where the scroll position had not changed since the previous frame. Nothing was dropped and the frame rate looks fine, but the eye sees the same picture twice. A high stale count alongside a healthy frame rate is the signature of input starvation rather than a slow renderer.

The browser batches raw input into one pointermove per rendered frame, so counting those events only tells you the frame rate. Calling getCoalescedEvents on each one returns every raw sample behind it, each carrying its own timestamp. The gaps between those timestamps are the report rate.

Yes. Polling rate is the mouse world's name for report rate: how many times a second the device tells the computer where it is. A 1000 Hz mouse and a 240 Hz digitizer are measured the same way here. A mouse often reads far below its rating in a browser, because the browser delivers one pointer event per frame and this page has to read the raw samples behind it.

No. Everything runs in the browser. No pointer data, no results and no device details leave the page.