How the ScreenTest.Pro Score Works

This is the methodology page. Nothing here is simplified for marketing; if the code and this page ever disagree, that’s a bug and we’d like to hear about it. (Benchmark version at the time of writing: 2.0.0.)

The question the benchmark asks

Most graphics benchmarks fix the workload and measure your frame rate. Ours inverts that: it fixes the frame-time target and searches for the heaviest workload your device can hold at it. The output is “max stable load” per scene — 840,000 nebula particles, say — which is what the score is built from.

Why inverted? Because frame rates saturate. On a fast machine, a fixed workload pegs at the display’s refresh rate and tells you nothing; the interesting question is how much more it could have handled. Searching for the ceiling keeps the measurement meaningful from a five-year-old phone to a desktop GPU, with the same scenes.

What runs

The Standard profile is five Signature scenes plus one control, each stressing a different axis:

Rendering runs at a capped pixel ratio (1.5×) with an internal size cap, so a 5K monitor and a 1080p laptop face comparable pixel counts. Randomness is seeded and simulation steps are fixed, so every run of a given version does the same work.

How stability is judged

The engine never reads an FPS counter. It collects frame times from the browser’s animation clock into windows of roughly 1.6 seconds, then asks two things of each window:

• mean frame time ≤ 16.67 ms × 1.08
• 95th-percentile frame time ≤ 16.67 ms × 1.28

The p95 test is the one with teeth: a machine that renders 100 quick frames and 6 nasty ones feels stuttery, and the percentile refuses to let the quick frames vote that away.

The 16.67 ms budget is fixed no matter what your display refreshes at. A 120 Hz screen delivers frames on an 8.3 ms cadence when things are easy, but passing only requires staying inside the 60-per-second budget — so high-refresh hardware is measured on equal footing, not punished for showing its extra frames.

The search

Each scene walks a state machine: preflight → baseline → warmup → ramp → bracket → confirm → anchor.

1. Baseline measures a known light load — this becomes the thermal reference.
2. Ramp multiplies the load ~1.6× per passing window until a window fails.
3. Bracket binary-searches between the last pass and the first fail until the range narrows to ~15%.
4. Confirm demands three consecutive passing windows at the candidate load. One bad window is retried (a notification or GC pause shouldn’t cost you the level); two consecutive failures reject it and the candidate steps down.
5. Anchor re-runs the baseline load. If it now runs >15% slower than at the start, the device changed under us — almost always thermal throttling — and the scene is flagged degraded instead of pretending nothing happened.

Every phase has a hard time limit (30 s per scene, 150 s per run). Backgrounding the tab pauses measurement and voids the current window; resizing rebuilds the scene and re-warms. There is no path through the state machine that hangs.

From loads to a score

Scoring is a pure function over the recorded results — you could recompute it by hand:

1. Each scene’s max stable load is divided by that scene’s reference load (a frozen calibration constant per version; roughly, a solid desktop from 2025 lands near 1.0).
2. Ratios are clamped to [0.05, 20] so no single scene can dominate or zero the result.
3. The clamped ratios combine in a weighted geometric mean — the five Signature scenes carry most of the weight, the Canvas 2D control 10%. Geometric, because it rewards balance: a machine great at everything beats a machine legendary at one thing and terrible at another.
4. Multiply by 1000, apply the stability deduction — 3% per thermally degraded scene, capped at 10% total — and round.

Tiers are fixed thresholds per version: Entry below 600, Balanced to 1499, Fast to 2999, Extreme above. They exist so a number has a handle; the subscores are the real information.

What invalidates comparisons

• Different benchmark versions never compare. Changing one shader changes the workload; the version string on your results sheet is part of the score.
• Compatibility runs (no WebGL2) use Classic scenes only and score in their own space, clearly labeled.
• Degraded runs carry their flag with them, including into our anonymous dataset, so public medians can exclude them.

Run-to-run variance, quantified expectations

On a plugged-in, idle machine, consecutive runs typically land within a few percent — the confirm phase’s consecutive-window requirement is what buys that. On battery, in power-saver mode, or with a warm chassis, expect more spread and a possible degraded flag; that’s not the benchmark being moody, that’s your device genuinely offering less. The browser-benchmark honesty piece covers what to do with the number once you have it.