How to Read a Frame Time Graph: Spikes, Lows and What They Mean

A frame time graph plots how many milliseconds each frame took to appear, so a flat, low line means smooth play and a spike means a stutter. Lower is better, and consistency matters more than the average. A game that holds 16.7 ms every frame feels smoother than one that averages the same but swings between 8 ms and 40 ms.

Average frames per second hides this, because it divides one number by another and smooths the bumps away. Frame time shows each frame on its own. This guide explains the axes, the conversion between milliseconds and fps, the shapes worth recognising, a worked example with invented numbers and what to do when a graph looks wrong.

What the axes actually say

The horizontal axis is time or frame number, running left to right through the capture. The vertical axis is frame time in milliseconds, with higher points meaning slower frames. Some charts flip this and plot fps instead, which turns spikes into dips, so check the label before interpreting the shape. Look at the scale as well: a graph zoomed to a narrow range can make small ripples look like disasters, and a wide range can hide real trouble.

Many capture tools exist; examples include overlay and logging utilities built on frame-presentation data. Each has its own settings and terms for summary figures, so read what the tool defines before comparing two reviewers’ charts.

The conversion table: milliseconds and fps

Frame time equals 1,000 divided by frames per second. The table lists common targets and the budget each one gives you per frame.

A frame that takes longer than the budget for your display’s refresh rate is a missed refresh. At 60 Hz a 50 ms frame spans three refresh intervals; at 144 Hz the same 50 ms spans more than seven. That is why a spike that barely registers on a 60 Hz screen can feel harsher on a faster one.

Reading the shape of the line

Four patterns cover most graphs you will meet.

• Flat band. Frames arrive at an even pace. This is the goal, and it is more important than a high average.
• Isolated spikes. Single frames far above the band feel like hitches. They often come from asset loading, shader compilation or background activity.
• Sawtooth or regular oscillation. A repeating up-and-down pattern suggests uneven frame pacing, which can come from frame limiters, sync settings or a mismatch between CPU and GPU work.
• Slow drift upward. Frame times climb as a session goes on. Thermal throttling, memory growth or a busy background process are typical suspects.

Context changes how you read all four. A flat band at 12 ms is excellent on a 60 Hz panel and disappointing if you bought a 240 Hz display, and a single spike during a loading screen means far less than one in the middle of a firefight. Ask where in the game the feature occurs and whether it repeats, before deciding it is a problem worth chasing.

Diagnostic table: what the pattern may mean

This table is a starting point, since symptoms overlap and several causes can act at once. Change one thing at a time and capture again.

Frame pacing, V-sync and variable refresh

A graph can look clean while the game still feels uneven, because what you see depends on when frames reach the display, not only when the GPU finished them. With V-sync on, a frame that misses a refresh waits for the next one, so frame times jump in steps tied to the refresh interval. With variable refresh rate (VRR, such as G-Sync or FreeSync) the display adjusts to the frame, which tends to soften the effect of small fluctuations inside the supported range.

A frame limiter can also change the graph. Capping fps a few frames below the refresh rate often gives a flatter line, since the GPU stops racing ahead and then stalling. If you compare graphs, make sure sync and limiter settings were the same, or the difference may come from the settings and not the hardware.

Capture habits that keep a graph honest

• Record the same scene or route each time, ideally 60 seconds or more.
• Close other programs, and note any overlay or recording software that stays open.
• Note the resolution, graphics preset, driver version and sync settings alongside the chart.
• Let the game finish its first-run shader work before recording, or record that stage separately.
• Repeat the run at least a couple of times and compare the shape, not just the numbers.

1% lows, 0.1% lows and the figures under the graph

Summary figures often sit beside the chart. A 1% low usually describes the performance of the slowest 1 percent of frames, but tools differ on whether they average those frames or use a percentile cutoff. A 0.1% low looks at an even smaller, worse slice and is more sensitive to rare spikes. Check each tool’s definition before comparing numbers from different sources.

Worked example with invented numbers

These figures are made up to show the arithmetic. Say a capture contains 600 frames over 10 seconds, and the average frame time is 10 ms.

The average says 100 fps, which sounds excellent, yet the 1% low sits at 40 fps and the worst frame lasts 60 ms. That gap is what a player feels as stutter. A second capture with an average of 90 fps but a 1% low near 75 fps would usually feel better despite the lower headline number.

Common mistakes when reading graphs

• Comparing charts drawn with different vertical scales and judging them by eye.
• Trusting average fps alone and ignoring the lows.
• Judging a long session from a 30-second capture of a quiet scene. Include busy moments.
• Leaving an overlay running that adds its own load.
• Blaming the graphics card for a CPU-side stutter, or the reverse.
• Reading one noisy run as proof. Repeat a capture to see what changes.

When you compare hardware, use the same game scene, settings and driver version across runs. If you are shopping, our lists of value gaming CPUs by frame goal, GPUs for 4K gaming and cost per frame graphics cards put these ideas to work in a buying context.

When to stop tweaking and look elsewhere

If stutter persists across several games, after a clean driver install and with temperatures in a normal range, the cause may be hardware. Signs include crashes, visual glitches, unusual fan behaviour or storage errors. At that point stop adjusting settings and run the maker’s diagnostic tools, check cables and seating, and contact support or the retailer if the part is under warranty. If one title alone misbehaves, look for a patch or a known issue in the developer’s notes before changing your hardware.

Frequently asked questions

What is a good frame time?

It depends on your target. Sixty fps needs about 16.7 ms per frame, 120 fps about 8.3 ms, and 144 fps about 6.9 ms. What matters most is consistency: a flat line near your target feels smoother than a lower average with large spikes. Aim for even frames rather than a single best number.

What is the difference between frame time and fps?

Fps counts how many frames arrive per second, while frame time shows how long each one took. Frame time is 1,000 divided by fps, in milliseconds. Fps averages hide irregular frames, so a frame time graph is better at revealing stutter that an average figure smooths over.

What does a spike in a frame time graph mean?

A spike is a frame that took much longer than its neighbours, felt as a hitch. Causes range from asset or shader loading and background tasks to thermal throttling or slow storage. Repeat the capture to see whether the spike appears in the same place, which helps separate game behaviour from your system.

How are 1% lows calculated?

Tools generally look at the slowest 1 percent of frames and report them as an fps figure, but the method varies. Some average those frames, others use a percentile cutoff. Read the tool’s documentation before comparing numbers from different programs, and treat the results as a guide to smoothness rather than a precise score.

Can a frame time graph show a CPU bottleneck?

It can hint at one. Spikes or a high band while GPU use stays low suggest the processor or game engine is limiting frames. Lowering resolution without improving frame times points the same way. Confirm by checking per-core CPU load and background processes, since several causes can overlap.