FPSCalc · free tools for players
Turn an average FPS and a 1% low into milliseconds per frame, then see what those slow frames really cost you: how many milliseconds they add, how much wall-clock time they occupy each minute, and the refresh rate your worst frames can actually sustain.
| Metric | Value | How it is derived |
|---|
| FPS | Frame time | Frame time | FPS |
|---|
Frame time and frame rate are the same number inverted. 144 FPS is 6.94 ms, 240 FPS is 4.17 ms, and 60 FPS is 16.67 ms.
| Refresh rate | Window (ms) | Your average fits | Your 1% low fits | Frames/sec at your average |
|---|
A frame that takes longer than one refresh window cannot be shown on that refresh; it waits for the next one. That is what a dropped frame is.
| Refresh intervals | Frame shown for | Effective FPS | Render time that lands here |
|---|
Frame time is how long each image took, in milliseconds: 1000 divided by FPS. 60 FPS is 16.67 ms per frame, 144 FPS is 6.94 ms. Average FPS hides pacing, because a handful of very slow frames barely move the average while being exactly what you feel as a hitch.
Percentiles are taken over frames, not over time. A 1% low is the frame rate below which only 1% of rendered frames fall. It does not mean you spent 1% of the session below that rate — four 500 ms outliers are still just 1% of frames but occupy far more than 1% of the wall-clock time. CapFrameX makes this point explicitly and offers a "time spent below threshold" view precisely because the two are not the same.
Two peer-reviewed studies give useful guide rails. Klein, Spjut, Boudaoud and Kim (IEEE CoG 2024) found 12 ms of frame time variation measurably degrades perceived smoothness, while 4 ms variation has a much smaller effect. The same authors at ACM 2024 found that smoothly varying frame time above 2 ms amplitude measurably lowers smoothness ratings at an unchanged mean. Those studies injected the variation themselves; this page only sees a tail percentile, so treat the band as guidance.
With double-buffered VSync a finished frame can only be presented on the next refresh boundary. A frame rendered in 8 ms cannot be shown after 6.94 ms, so it waits for the boundary after that and is displayed for 13.89 ms — 72 FPS. The frame rate collapses in steps instead of sliding: from 144 to 72, then 48, then 36. Triple buffering and variable refresh rate avoid the halving, which is why G-Sync and FreeSync exist.
Look at your 1% low rather than your average. The refresh rate whose window still contains your slowest frames is 1000 divided by your 1% low frame time, rounded down. If that is below your monitor's refresh rate those frames cannot make every refresh, and buying more average FPS will not smooth them out. Fixing the pacing does far more than raising the average.
A wide gap between average and 1% low points at pacing rather than raw power; a 0.1% low that is far worse than your 1% low points at rare hard hitches. Common causes worth testing in order: a CPU render-thread limit, background tasks, shader compilation on a first pass, asset streaming from slow storage, and running out of VRAM. Cap the frame rate just below your sustainable refresh rate and check whether the low improves — that single test tells you whether you are chasing power or consistency.