Frame Pacing Explained: Why Stable Frames Matter More Than Average FPS

Average FPS tells you how many frames a game produced across an interval. It does not tell you whether those frames arrived at useful, regular moments. A steady 60 FPS gives each frame about 16.7 milliseconds; a sequence that alternates between early and late frames can report the same average while motion looks uneven.

That timing pattern is frame pacing. This article explains the player-facing idea and a practical way to inspect it. It does not benchmark a particular game or promise one universal “good” frame-time graph. The evidence comes from platform presentation documentation and the metrics exposed by PresentMon.

One average can hide two timelines

FPS is a rate. Frame time is a duration. They describe the same stream from different directions, but an average rate compresses the order of events into one number.

At common targets, the ideal duration for one frame is simple division:

Target rate	Approximate time available per frame
30 FPS	33.3 ms
60 FPS	16.7 ms
90 FPS	11.1 ms
120 FPS	8.3 ms

Now compare two six-frame windows. Both average roughly 60 FPS.

Frame	Even delivery	Uneven delivery
1	16.7 ms	8.3 ms
2	16.7 ms	25.0 ms
3	16.7 ms	8.3 ms
4	16.7 ms	25.0 ms
5	16.7 ms	8.3 ms
6	16.7 ms	25.0 ms

The first sequence advances at a regular cadence. The second bunches a short interval beside a long one. Its average preserves the total throughput and discards the rhythm. A player following a camera pan or a moving target sees that rhythm, not the spreadsheet average.

This is why a lower, stable cap can look calmer than an uncapped rate that repeatedly overshoots and falls back. It is not a rule that lower is always better. The useful target is one the entire presentation pipeline can meet consistently under the scene you actually play.

Rendered is not the same as displayed

A frame passes through several stages: the game updates its state, the CPU submits work, the GPU completes it, and the display presents an image. Those stages can queue and wait. A counter positioned at one stage does not automatically describe the others.

Android’s frame-pacing documentation defines the problem as synchronizing the game loop with the operating system and display hardware. It gives two revealing failure cases. A short game frame followed by a long one can make displayed durations uneven. A backlog of long frames can also add latency when buffers fill. The frames exist, but they are not reaching the display at a useful cadence.

Microsoft documents the same queue pressure from the application side. Its Direct3D 12 swap-chain guidance warns that letting the CPU run ahead without limiting frames in flight can build a queue and increase input latency. More completed work is not automatically fresher work.

The practical distinction is:

• production time asks how long the application and GPU spent making a frame;
• presentation interval asks how long the previous image remained visible before the next displayed image replaced it;
• end-to-end latency asks how much time passed between an input and the image that reflects it.

They influence one another, but they are not interchangeable. A frame-rate overlay may show an acceptable rate while a presentation graph exposes irregular display intervals. A smooth graph can coexist with substantial fixed latency if a queue is holding several frames ahead.

Read the timeline before the percentile

Performance tools often summarize a capture through an average plus low-percentile FPS figures. Those summaries are useful comparisons, but they still compress the order of events. Two captures with the same low can feel different if one has a single isolated spike and the other has a repeating long-short pattern.

PresentMon records one row per presented frame and exposes several timings rather than one master number. Its documented fields include time between presentation calls, time between display changes, CPU and GPU work durations, and display latency. Not every metric is available or equally accurate under every graphics path; the project specifically documents limitations for some OpenGL, Vulkan, and hardware-scheduling cases.

For a player-facing diagnosis, start with three views:

1. The frame-time timeline. Look for isolated spikes, repeating teeth, or a broad rise during one scene.
2. The distribution. Check whether most frames stay near the target or whether the average is held together by extremes.
3. A matched event. Note what happened when the spike appeared: a camera turn, area transition, effect, menu overlay, or background task.

The third view keeps the graph honest. A line without the scene context cannot tell you whether the game streamed an area, compiled work, waited for the GPU, or was interrupted elsewhere on the system.

Four patterns, four different questions

Treat a graph as a way to narrow the next test, not as a diagnosis by silhouette.

Pattern you observe	What it means at the screen	Useful next question
One tall, isolated spike	One image remained longer than its neighbors	Does it recur at the same transition or was it a one-off interruption?
Repeating long-short teeth	Frames are arriving in an uneven cadence	Do the pattern and target rate align with the display refresh and chosen cap?
Frame time rises and stays high in one scene	The current workload exceeds the earlier budget	Which setting changes that scene without altering unrelated parts of the pipeline?
Stable intervals with controls that still feel late	Cadence is regular, but response may be buffered elsewhere	Is there a frame queue, VSync behavior, display latency, or an input-layer issue?

The last row matters because smoothness and responsiveness are related but separate. A stable queue can deliver perfectly even old frames. Conversely, low-latency delivery can tear or look uneven when synchronization is relaxed.

Local input also has its own filters before a game responds. If small stick movement seems absent rather than merely late, inspect the controller dead-zone signal path before assigning the problem to rendering. In online play, rollback corrections add another timeline after local simulation begins.

Use a controlled settings ladder

Randomly lowering every graphics option can improve a number and teach you nothing. Change one layer at a time, record the same demanding route or scene, and keep the target explicit.

1. Choose a target the slow scene can approach

An uncapped menu or quiet room can inflate the average far above the rate reached during play. Start from the demanding repeatable section, not the easiest one. A cap below the unstable ceiling can create headroom for variation, provided the cap itself is delivered evenly.

2. Separate sustained load from momentary spikes

If the whole scene sits above the frame budget, reduce a setting that plausibly affects sustained work and repeat the same route. If only transitions spike, lowering a steady-state visual setting may not touch the cause. The pattern determines which experiment is worth running.

3. Change presentation policy separately

Frame cap, synchronization mode, display refresh, and any low-latency option affect when finished work is presented or queued. Test these apart from image-quality settings. Otherwise a smoother result cannot be attributed to the workload change or the delivery change.

4. Keep the capture conditions comparable

Use the same area, route, resolution, and approximate duration. Note patches and driver changes. Close or preserve the same background workload. A comparison is only as good as the conditions that remained fixed.

This is an observation method, not a claim that every game exposes the right controls. Consoles and mobile games may choose pacing policy for the player. PC titles may label similar behaviors differently. The graph can show the outcome without revealing every internal switch.

What a smooth counter cannot promise

Frame pacing does not replace image quality, simulation performance, input latency, or network stability. It describes the temporal arrangement of displayed work. A good cadence cannot rescue a rate too low for the motion you need, and a high rate cannot excuse repeated stalls.

Nor is one percentile a verdict across games. A slow strategy map, a rhythm game, and a competitive shooter expose timing errors differently. Display technology and synchronization policy change what reaches the eye. Tool limitations change what a capture can prove.

The useful question is narrower: does the game deliver frames near the chosen interval during the moments that matter? If not, the timeline shows whether you are hunting a persistent budget problem, a recurring pacing pattern, or a rare interruption. That is more actionable than asking an average FPS counter to describe time after it has averaged time away.