Understanding Frame Time and Lag in the Volume Shader BM Test
Understand FPS, milliseconds per frame, and browser timing in the Volume Shader BM Test, including what its current metrics can and cannot measure.
Average FPS describes how much animation work the browser completes. Frame timing describes how evenly it is scheduled. Both help when comparing runs, but they do not identify the cause of a slowdown by themselves.
What the current benchmark measures
The Volume Shader BM Test runs a WebGL shader at a fixed 1024 × 1024 drawing-buffer size. Its numeric panel reports current, average, minimum, and maximum FPS, milliseconds per frame, active running time, and rendered-frame count.
Current FPS is sampled over short reporting windows. Minimum and maximum FPS describe those reported windows; they are not the slowest individual frame, a 1% low, or a percentile. Average FPS divides rendered frames by active running seconds. Pausing or leaving the visible tab does not turn idle time into slow benchmark frames.
The tool does not provide a lag-spike counter, per-frame history chart, input-latency measurement, or GPU temperature reading. Use the numeric panel for an overview and browser profiling tools when you need a detailed timing trace.
Converting FPS to milliseconds
For a steady rate:
milliseconds per frame = 1000 / FPS
FPS = 1000 / milliseconds per frame
| Rate | Frame budget |
|---|---|
| 30 FPS | 33.33 ms |
| 60 FPS | 16.67 ms |
| 120 FPS | 8.33 ms |
| 144 FPS | 6.94 ms |
These are mathematical conversions, not expected scores for a specific GPU. The FPS and frame-time calculator handles other values and compares changes between two rates.
Why an average can hide uneven frames
Consider two illustrative sequences of frame intervals:
Sequence A: 16 17 17 16 17 17 -> total 100 ms
Sequence B: 5 5 40 5 5 40 -> total 100 ms
Both sequences represent six frames over 100 milliseconds, or 60 FPS over that interval. Sequence B includes much longer gaps. An average alone cannot describe that difference. The current benchmark's short-window readout can expose sustained changes, but it cannot reconstruct individual gaps that happened inside a reporting window.
Browser timing is not a hardware stopwatch
The animation loop uses browser frame callbacks. Those callbacks depend on display refresh, browser scheduling, power settings, and whether the tab is visible. A result near 60 FPS on a 60 Hz display may indicate a scheduling ceiling rather than a GPU that cannot render faster.
Use the refresh-rate test to estimate the browser's callback cadence. That estimate is also browser timing, not direct panel hardware identification. Keep the same browser and display when comparing benchmark runs.
Investigating visible stutter
Start with a controlled repeat:
- Restore the default shader and camera.
- Close competing GPU applications and keep the test tab visible.
- Run for the same active duration, then pause and save JSON or CSV.
- Repeat under the same power and browser settings.
- If stutter persists, record a browser performance profile to inspect individual animation frames and long tasks.
A low or changing FPS value can suggest a problem worth investigating. It cannot distinguish heat, driver behavior, CPU scheduling, or background work on its own. Our low-FPS troubleshooting guide gives a practical sequence for isolating those variables.
Treat frame-time conversion as a way to understand a rate and the benchmark as one browser workload. Neither establishes input lag, gaming performance, or hardware health by itself.