Measurements and tests
Polling rate and timing
A pad tells the computer its state in reports, many times a second. How often it does is its polling rate, in hertz: 1,000 Hz is a report every millisecond, 250 Hz one every 4 ms. The Polling rate tile shows it, and the Timing tab how evenly the reports come.
The polling rate
The tile shows the latest rate, and the highest since the pad connected: a rate the pad kept for two readings in a row, so a count that jumps for one second is not taken for one, and never below the latest. Under it, a line says what was counted.
No rate is marked good or bad. The figure is what the pad does, to compare with what its maker claims.
Every report
Through WebHID, in Chrome and Edge, and in the Windows app, PadBench sees each report the pad sends, so the figure counts them all: the pad's true report rate. The app reads up to 8,000 a second.
State changes, not reports
The Windows app reads Xbox pads through XInput, which passes on a pad's state only when something changes. The figure then counts changes, and says so: a pad held still reads low, however often it reports, so it isn't the pad's polling rate.
Capped by the browser's polling
Under the figure, Capped by the browser's polling means it counts how often the browser passed the pad's state on, not every report the pad sent, so it can go no higher than the browser's own pace: Chrome reads a pad every 4 ms at most, so every rate past 250 Hz would read alike. Where that pace is all there is to count, PadBench shows no figure at all, as the next part says.
Not measurable here
The browser's Gamepad API hands PadBench one reading per screen refresh, so it can't count the pad's own reports. PadBench then shows no figure at all, rather than the browser's pace dressed up as the pad's. Where Chrome or Edge can open the pad through WebHID, Use WebHID in the tile reads it directly and counts every report.
The Timing tab
Where every report is counted, the Timing tab shows the average interval between reports, and from the latest 2,000 of them, the last two seconds at 1,000 Hz: the median interval, the usual one; the jitter, how far the slowest report in a hundred strays from the median (p99 − median); the longest gap; and a histogram of them all.
A steady pad shows one tall bar. A wide spread or long gaps, as Bluetooth often gives, mean some presses wait longer than others to be sent.
Why there is no latency figure
A press waits at most one report interval to be sent. The rest of the delay, inside the pad from the switch to its report, is invisible to software, so any latency figure would be a guess, and PadBench shows none.