๐ŸŽฎController and screen tests

Two kinds of hardware you argue with rather than about. Both give a number here: a drift score with a threshold, and a refresh rate measured from frames the browser was actually handed.

โœ“ Tested & verified Updated: How the test works

A controller and a monitor fail in the same frustrating way: gradually, and always with someone willing to tell you it is in your head. The camera creeps left when nobody is touching the stick. The screen feels no smoother than the old one. Both arguments end the moment there is a figure on the table, which is what this group produces.

For the controller, start with gamepad tester to confirm every button and axis is answering and correctly mapped โ€” a controller that seems broken is often just presenting a different layout than the game expects. Then run the stick drift test, which samples both sticks at rest with no deadzone applied and turns the result into a score with a stated threshold. That distinction is the whole point: a game’s deadzone can mask real drift for months, so the only honest measurement is one taken without it.

For the display, the refresh rate test reports the rate the browser was actually handed and the matching frame time in milliseconds, which is how you catch a 144 Hz panel quietly running at 60. Screen resolution shows the CSS pixels, the device pixel ratio and the physical pixels together, so a scaled display stops being confusing. The dead pixel test fills the screen with flat colours โ€” the only reliable way to find a single failed dot โ€” and includes a cycling mode that sometimes frees a stuck one. The touch screen test covers the same ground for panels you press instead of look at: which points register, how many at once, and whether any area has stopped responding.

Frequently asked questions

How much stick drift is still normal?

A stick at rest should report values hovering within a few hundredths of zero. Movement past that with your hands off the controller is drift, and once it is large enough to move a camera or a cursor on its own, it will not settle down again โ€” potentiometer wear is one-directional. The drift test turns the resting deviation into a score so you can compare the same stick a month apart instead of relying on how it felt last time.

How is drift different from a deadzone?

A deadzone is the game’s answer to drift: it ignores small stick values so a slightly worn stick still behaves. That is why a controller can be visibly drifting here and feel fine in one game and unplayable in another โ€” the games are applying different deadzones to the same signal. This test deliberately applies none, which is the only way to see what the hardware is really sending.

Is it a dead pixel or a stuck one?

The colour tells you. A pixel that stays black on a white screen is dead โ€” its transistor has failed and there is nothing to revive. A pixel showing a fixed red, green, blue or white dot on a black screen is stuck: the subpixel is jammed on rather than broken off. Run the test twice, once on white and once on black, and the difference is obvious.

Can a stuck pixel be fixed?

Sometimes, and the odds are better the newer the fault. Cycling colours rapidly over the area exercises the subpixel and occasionally frees it, which is why this site includes a cycling mode; leave it running for a quarter of an hour or so. It does nothing for a genuinely dead pixel, and there is no software that can โ€” that one is a panel replacement or nothing.

Why does my 144 Hz monitor test at 60 Hz?

Because the browser measures the frames it was actually handed, and something upstream is capping them. The usual causes are a cable or port limited to 60 Hz at your resolution, a display setting still on the default rate, browser hardware acceleration switched off, or a laptop on battery in a power-saving mode. Change one at a time and re-run โ€” the reading is the fastest way to find out which one it was.

Why does the resolution here not match my display settings?

Because they are two different measurements. The browser reports CSS pixels, and your operating system’s scaling multiplies them: at a device pixel ratio of 2 a 2,560-pixel-wide panel reports 1,280 to the page. Neither figure is wrong, which is why both are shown side by side along with the ratio between them, and the physical width is the two multiplied together.

How the test works

Controller readings come straight from the Gamepad API: buttons report a pressed state and an analogue value, and each axis reports a normalised figure between โˆ’1 and 1 rather than an angle or a degree count. The drift score is our own definition, because there is no standard one โ€” it is built from how far a resting stick deviates from centre and how much that deviation wanders over the sampling window, expressed on a 0 to 100 scale, and the page states the thresholds it uses rather than asking you to trust a verdict. No deadzone is applied anywhere, since a deadzone is exactly what hides the thing being measured. Refresh rate and frame time are derived from requestAnimationFrame timestamps, so the figure is the rate of frames the browser was actually handed and can legitimately be lower than the mode your display is set to; frame time in milliseconds is 1,000 divided by that rate. Resolution is reported twice โ€” in CSS pixels as the page sees it and multiplied by the device pixel ratio for the physical count โ€” because on a scaled display those are different numbers and only one of them is what the panel has. The pixel tests are visual by design: full-screen flat colours are the only reliable way to find a single failed dot.

Sources:

More things worth testing