Game frame pacing: control presentation cadence and queue latency

Purpose

A game can report a satisfactory average frame rate while motion still judders. The visible result depends on when completed images reach the display and how long each remains visible. Frame pacing coordinates this delivery with the display instead of treating every completed render as an instruction to present immediately. It also limits unnecessary queued work that makes an input change wait behind older frames.

How it works

On a fixed-refresh display, presentation opportunities occur at discrete intervals. Vulkan's VK_PRESENT_MODE_FIFO_KHR queues presentation requests in order and is the required supported mode. VK_PRESENT_MODE_MAILBOX_KHR, when available, replaces a pending request with a newer one before presentation. That replacement policy does not remove work already queued elsewhere on the GPU.

Swapchain image count, application frames in flight and the presentation queue describe related but different resources. A fence-based submission limit can control outstanding work. A platform pacer may combine scheduling timestamps with synchronization waits; Android's library explicitly addresses early presentation and queue stuffing. Choose the policy using the actual surface capabilities and workload.

Worked example

Assume a fixed display rate of 60 Hz and a game target of 30 frames per second. Each refresh lasts approximately 1000 / 60 ≈ 16.67 ms. Showing every game image for two refreshes produces a cadence of about 33.33 ms.

Alternating one-refresh and three-refresh visibility instead produces intervals near 16.67 ms and 50 ms. The average rate can still match the target, while the cadence is visibly uneven. This is an illustrative schedule, not a measurement or a guarantee about a particular display compositor.

Practical workflow

Capture input sampling, CPU submission, GPU completion and actual presentation timestamps where the platform exposes them. Keep clock domains explicit; returning from a submission call is not proof that the image was already displayed. Inspect the interval distribution and repeated images, rather than relying only on an FPS counter.

Select a supported presentation mode, set an achievable cadence and bound outstanding frames. Compare latency and missed deadlines while varying the bound. Test a steady camera pan, deliberate workload spikes and transitions between display refresh modes. Preserve enough parallel work to use the GPU effectively without accumulating avoidable presentation delay.

Limits and verification

A pacing library cannot finish an expensive frame before the hardware completes it. Lowering a target may improve regularity, but the chosen display mode must support the intended cadence. Variable-refresh displays introduce different timing opportunities and limits; the fixed-refresh example should not be applied unchanged.

Mailbox presentation can discard older pending images, but rendering unnecessary images still consumes resources. Verify sustained behavior, power use and input latency on target devices. Record the selected mode, refresh rate and pacing settings with each capture so a smooth result can be reproduced.

Sources

• Android Frame Pacing library — Google, Android Developers
• VkPresentModeKHR — Khronos Group, Vulkan Documentation Project