Why CapFrameX Shows Lower FPS Than Your Game's Counter
Updated
CapFrameX often reports a lower average FPS than the in-game counter because the two tools measure different things over different time windows. CapFrameX captures every frame's frametime through Intel's PresentMon and then derives FPS from that complete frame data, while an in-game counter typically shows a smoothed, instantaneous rate. The gap is expected, not a bug, and it usually means CapFrameX is giving you the more honest number for the captured period.
Where the difference comes from
Frametime vs. FPS as the raw measurement
CapFrameX records frametimes — the time each frame takes to render — and calculates FPS from them. The site's own blog post "The challenge of displaying performance metrics as FPS" addresses exactly this question: why analysis shows FPS values lower than what you saw in the game.
An in-game counter is usually a running average or a smoothed instantaneous value, updated frequently and often rounded. It answers "how fast does it feel right now." CapFrameX answers "what did every captured frame actually cost," which is a stricter question.
The averaging method matters
A simple average of FPS values is not the same as the reciprocal of the average frametime. Because FPS is a rate (frames per second), short slow frames — the stutters — pull the average down more than they appear to in a smoothed counter. If CapFrameX reports a lower average, it is often because those slow frames are included rather than averaged away.
The capture window is complete, not selective
The in-game counter runs continuously and you tend to read it during the smooth parts. CapFrameX analyzes a defined capture window that includes loading transitions, shader compilation hitches, and scene changes if they fall inside it. A capture that includes a single heavy spike will show a lower average than the counter you glanced at during normal play.
How to read the numbers correctly
| Metric | What it tells you | Why it can differ from the game counter |
|---|---|---|
| Average FPS | Mean rate across all captured frames | Includes slow frames the counter smooths out |
| Frametime | Cost of each individual frame | The raw data; FPS is derived from it |
| Median | Middle frame's performance | Less affected by a few extreme spikes |
| Percentiles | Distribution of frame performance | Shows consistency the average hides |
| x%-low | Average of the worst x% of frames | Surfaces stutter the counter never shows |
The site's "metrics explained" post covers frametimes, FPS, median, percentiles, and x%-low, and is the reference for how CapFrameX calculates each one.
Practical steps to make a fair comparison
- Capture a representative window. Start recording after the scene has loaded and shaders have compiled, so the capture reflects gameplay rather than startup.
- Compare like with like. Put the in-game counter and CapFrameX side by side over the same segment. If the counter is a smoothed average, expect it to sit above the CapFrameX average.
- Look past the average. Check median and x%-low. A high average with a poor x%-low means the game feels worse than the average suggests — and that is the information the in-game counter is hiding.
- Repeat the capture. One run can be skewed by a single background task. Two or three captures of the same route give you a stable picture.
When a lower number is actually a problem
A lower CapFrameX average is normal. It is worth investigating when:
- The gap is large and consistent, not just a few percent.
- x%-low is far below the average, indicating regular stutter.
- Frametime shows periodic spikes at a fixed interval, which can point to a background process or a driver issue rather than the game itself.
In those cases the difference is not a measurement artifact — CapFrameX is showing you a real performance characteristic that the in-game counter does not surface.
The takeaway
Treat CapFrameX as the detailed record and the in-game counter as a quick glance. When they disagree, CapFrameX is usually right about the captured window, because it works from complete frametime data rather than a smoothed rate. Use the average for a headline figure, and median, percentiles, and x%-low to judge how the game actually feels.