Android Systrace Basics - Why 60 FPS?

Word count: 1.6kReading time: 9 min

 2019/05/27

Technical update — 2026-10-13: First published in 2019, this article uses 60 Hz devices to explain frame pacing. 60 FPS is not a fixed standard for every Android device. The universal 16.67 ms budget, mismatched-rate examples and power claims are corrected below, with updated tools available from Android 11 / API 30 and Android 12 / API 31.

This is the third article in the Systrace series, explaining why 60 FPS is constantly emphasized. Here, FPS describes the app’s content frame rate, while Hz describes display refresh rate; they measure different things. For further context, refer to: A New Smooth Experience: A Talk on 90Hz.

The purpose of this series is to view the overall operation of the Android system from a different perspective using Systrace, while also providing an alternative angle for learning the Framework. Perhaps you’ve read many articles about the Framework but can never remember the code, or you’re unclear about the execution flow. Maybe from Systrace’s graphical perspective, you can gain a deeper understanding.

This article separates frame rate from refresh rate, then discusses pacing, power and response latency. On 90 Hz and 120 Hz devices, content updates still need to work with display timing, but 60 FPS and 16.67 ms are no longer universal targets.

Series Article Index

Main Content

Today, let’s discuss why we start with 60 FPS when talking about smoothness.

First, let’s clarify some basic concepts:

60 FPS means 60 frames per second, but specify whether you are counting frames generated, submitted or presented. Submitting 60 frames does not prove that the display showed 60 distinct content updates.
The same average frame rate can produce different experiences. Continuous motion should be presented at reasonably even intervals; alternating short and long intervals creates an uneven cadence.
If 60 frames are presented evenly each second, new content appears every 1000 / 60 = 16.67 ms. That is a target interval, not something an average of 60 FPS automatically guarantees.

Early Android explanations often targeted 60 FPS because a common display mode was 60 Hz: ideally, a new frame would be ready for every refresh. This explains continuous animation, but Android does not guarantee a new frame on every Vsync, and a static page need not keep redrawing to fill a 60 FPS quota.

Basic Concepts

FPS describes content frame rate; Hz describes display refresh frequency. In a fixed 60 Hz mode, the nominal period is 16.67 ms. A device may support several modes, with the active mode also depending on content, system policy and power conditions. A panel advertised as supporting “up to 120 Hz” need not currently be running at 120 Hz. Vsync coordinates rendering with display timing; it does not mean every software callback executes at the instant of physical refresh. AOSP multiple refresh rates

Fixed refresh mode	Nominal refresh interval	Target for continuous animation updated on every refresh
60 Hz	16.67 ms	60 FPS
90 Hz	11.11 ms	90 FPS
120 Hz	8.33 ms	120 FPS
144 Hz	6.94 ms	144 FPS

These intervals are simply 1000 / Hz. Android does not forcibly run a full measure, layout and draw pass at each interval. Nor must all work on the main thread, RenderThread, GPU, SurfaceFlinger and display execute serially within one interval. Rendering can be pipelined. Assess a frame against its scheduling phase, deadline, GPU completion and presentation time; a main-thread slice shorter than 16.67 ms alone does not prove that the frame was free of jank.

Raising both refresh rate and content frame rate usually adds display and rendering work, but it does not establish a linear relationship between Hz and whole-device power. Workload, resolution, brightness, display mode and device implementation affect the result. Display constraints such as TFT write timing also depend on the specific panel. Measure power differences on the same device under comparable workloads.

Performance Gains

Different frame and refresh rates do not automatically cause jank. Steady 30 FPS content can hold each frame for two refresh cycles on a 60 Hz display; 60 FPS content can do the same at 120 Hz. The content frame count has not increased, but the cadence can remain even. Conversely, matching averages of 60 do not prevent stutter if submission and presentation intervals are uneven. Android Frame Pacing

For the same constant-speed motion, if both rates are presented steadily, 60 FPS shortens the interval between new images from about 33.33 ms to 16.67 ms compared with 30 FPS. The position change between adjacent frames is also smaller. Full response time still includes input, app processing, queueing and display, so doubling FPS does not guarantee halving touch latency.

The original two examples need qualification:

60 FPS content on a fixed 75 Hz display: 75/60 is not an integer. If frames are repeated to match the display without a mode switch, each content frame cannot occupy the same number of refresh cycles, which can produce uneven cadence. “No benefit, only wasted power” is too broad a conclusion.
60 FPS content on a fixed 30 Hz display: there are at most 30 display updates per second, so all 60 distinct updates cannot be presented. Whether excess frames are replaced, dropped or cause the producer to wait depends on the buffer queue and submission behavior. Exactly half being discarded is not a universal rule.

Higher refresh rates can also improve matching for lower-rate content. For example, 24 FPS video usually needs a 3:2 repeat cadence at fixed 60 Hz, whereas 120 Hz can hold every video frame for five refresh cycles. That reduces this source of judder without turning the video into 120 FPS content. It also does not make the latency requirements of film and interactive interfaces identical. Android frame rate API

This was my suggestion at the time, kept here as part of the original discussion, not as current buying advice:

If you want to experience a 120 Hz screen, I suggest trying an iPad Pro. You’ll notice that 60 Hz screens definitely have room for improvement.

The original videos remain as historical further reading. Distinguish content frame rate, display cadence and interaction latency; the titles do not establish a universal threshold for smoothness:

The original frame-stage chart is retained below. Its legend includes VSync, input, animation, Traversal, Draw, Sync and Frame Completed markers, which help illustrate the rendering stages discussed at the time:

Historical rendering frame-stage chart

The chart does not include its original trace, device or Android version. Colors and bar heights alone cannot establish the exact measurement definitions for every stage, independent GPU execution time or full input-to-display latency. Profile GPU/HWUI rendering in Developer options also changes its segments across system versions. Its 16.67 ms reference line targets 60 FPS; it is not a universal acceptance threshold for all refresh modes. Official rendering inspection guide

Checking Modern Android Devices

Establish the intended cadence. Check the active display mode and target content frame rate. Static pages, video, games and continuous scrolling have different goals. A refresh-rate overlay is not an app FPS counter.
Express frame-rate intent. From Android 11 / API 30, Surface.setFrameRate() lets a Surface express its intended frame rate. The system may choose another rate, and the call does not automatically change the app’s render loop. Games can use Frame Pacing (Swappy) to control submission timing and avoid extra latency from a backed-up buffer queue.
Inspect actual frames and deadlines. From Android 12 / API 31, capture FrameTimeline and correlate App/SurfaceFlinger Expected/Actual Timelines, frame associations and thread scheduling. Missing data is not evidence of zero jank. FrameTimeline alone also does not replace a full input-to-display latency measurement.

Continue with the Perfetto series index or high refresh rate benefits and challenges.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”