Android Perfetto Series 6: Why 120Hz? Advantages and Challenges

Word count: 2.6kReading time: 16 min

 2025/04/26

120 Hz reduces the nominal refresh interval from 60 Hz’s 16.67 ms to about 8.33 ms. Display refreshes, app-produced frames, and distinct frames presented are different counts. This article uses a historical Perfetto trace to explain their relationship and the rendering/power trade-offs.

Part five covered Choreographer callbacks; here the focus is the shorter display cycle. The screenshots describe that capture, not every 120 Hz device’s scheduling configuration.

Version note (reviewed October 2026): The 2025 screenshots are retained without their original trace or device-build details. Buffer counters are explained against android-15.0.0_r1; frame-rate hints start at API 30, while ARR is discussed separately from Android 15. 120 Hz is the mode examined here, not a universal device requirement.

Perfetto Series Catalog
Basic Concepts
System Implementation and Principles
Advantages and Challenges of 120Hz
Thoughts and Future Outlook
Conclusion
About Me && Blog

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

Find ways to get in touch on the About Me page to discuss your problems, the parts about Perfetto you most want to see, and discuss all Android development related content with group friends.

Basic Concepts

What is Screen Refresh Rate?

Screen refresh rate is a hardware concept, referring to the number of times the screen refreshes the display content per second, in Hertz (Hz).

60Hz screen: Refresh 60 times per second, each refresh interval is about 16.67ms
90Hz screen: Refresh 90 times per second, each refresh interval is about 11.11ms
120Hz screen: Refresh 120 times per second, each refresh interval is about 8.33ms

The active screen mode limits how often a new frame can be displayed. A refresh can repeat the previous frame, and devices with adaptive refresh rates need not stay at one fixed frequency.

What is FPS?

FPS (Frames Per Second) needs a measurement target: it may count frames produced by an app or distinct new frames actually presented on screen.

The following assumes evenly paced frames; average FPS alone does not establish each interval or processing duration.

60FPS: About 16.67ms between successive frames; this is not necessarily the time spent processing each frame
90FPS: About 11.11ms between successive frames
120FPS: About 8.33ms between successive frames

A lower app frame rate is not automatically jank. A 24 FPS video can legitimately repeat frames on a 120 Hz display; inspect expected/actual presentation and cadence for interactive content.

Content Type Difference:
- Video Content: 24 or 30 FPS video need not synthesize 120 distinct images. Smooth playback still depends on regular presentation cadence and the chosen display mode.
- Interactive Interface: Scrolling and direct-manipulation animations need consistent response. An occasional long frame can be noticeable even when average FPS remains high.
Frame Rate Stability: Irregular frame intervals can be noticeable even when average FPS is high; compare frame presentation times in the same scene.
System Behavior:
- When FPS is lower than the refresh rate, the display can repeat an earlier frame; a black frame is not the normal fallback.
- When an app produces frames faster than the display can present them, some work may not become a distinct visible frame; check buffer and presentation records before calling it a dropped frame.

Different application scenarios have different smoothness standards, and developers need to choose appropriate optimization strategies according to the application type.

What is Vsync?

Vsync (Vertical Synchronization) provides display-related scheduling points for apps and SurfaceFlinger. Choreographer requests a callback when an app has pending frame work; not every display Vsync makes every app render a new frame.

Why 120Hz Became the New Standard?

120 Hz provides more update opportunities when the content and device can use them:

Smoother motion: An app producing distinct frames steadily can show more intermediate states in scrolling and animation; static content has no equivalent gain.
Less wait for a refresh opportunity: The nominal interval falls from 16.67 ms to 8.33 ms. Input dispatch, app/GPU work, and composition remain part of end-to-end latency.
Device capability: Chip, panel, and thermal limits determine sustainable performance; a supported mode does not guarantee 120 FPS content.
Power management: Content and interaction policies can avoid unnecessary high-refresh operation.
Variable refresh: Supported rates and policies differ. Mode switching and ARR’s within-mode adjustment are separate mechanisms, and LTPO alone does not establish Android ARR support.

Apple’s ProMotion provides a useful comparison for content-aware pacing. Its animation guidance below is not an Android device configuration.

System Implementation and Principles

120Hz Rendering Process from Perfetto’s Perspective

A fixed 120 Hz mode has a nominal 8.33 ms interval. Main-thread, RenderThread, GPU, and SurfaceFlinger stages can overlap across frames rather than run serially in that window. This is the historical capture:

120Hz App Rendering Flow

Vsync cadence: The selected 8.326 ms interval approximates 120 Hz. VSYNC-app is a software timing counter; its high level is not execution duration or independent proof of the hardware mode.
Callbacks and deadlines: Choreographer processes due Input, Animation, Insets Animation, Traversal, and Commit callbacks. The “8.33 ms available to the app” annotation illustrates an interval. Actual remaining time depends on callback start, deadline, and FrameTimeline prediction.
GPU and submission: RenderThread is a CPU thread. Arrow 4 groups GPU work and buffer queueing schematically; queueBuffer establishes neither simultaneous GPU start nor completion.

Interpret the counters against the captured build. In Android 15 BLASTBufferQueue:

QueuedBuffer is emitted in the app process as mNumFrameAvailable + mNumAcquired - mPendingRelease.size(). It combines available and acquired states while subtracting pending releases; it is neither the raw BufferQueue length nor GPU completion.
BufferTX counts pending buffer transactions on SurfaceFlinger’s side. Android 15 Layer uses mPendingBufferTransactions, traced as BufferTX - plus the layer name. The field is not universally named mPendingBuffers.

A typical path is:

App submission reaches BLAST’s onFrameAvailable, updating its counter. Acquisition and transaction construction depend on synchronization/queue state; the acquire fence may still be pending.
SurfaceFlinger increments the layer’s pending count for a valid buffer transaction; latch or drop paths decrement it. A decrease is not presentation.
Unneeded buffers return through release callbacks and fences. BLAST can retain some pending releases, and a callback or counter decrease does not guarantee immediate safe reuse: the release fence still matters. Merely displaying static content for a long time does not automatically release its buffer.

The next image associates app frame 54161669 with a SurfaceFlinger frame. App Actual Timeline ends at completion of app/GPU work and posting, not final presentation; SF Actual Timeline extends to presentation. The red “over 50 ms” label is not 50 ms of continuous SF computation or main-thread blocking. The separate 23.58 ms selection is not a substitute for that measurement. Without the trace, no precise end-to-end latency is recalculated here.

Check frame tokens, layer, linked DisplayFrame, Present Type, and Prediction Type. Light green can indicate high latency, so color alone does not prove prompt response. See FrameTimeline documentation and part one.

System Architecture Optimization Supporting 120Hz

Sustained high-refresh operation requires control of frame timing and power. Display-rate selection is one part of that work.

Adaptive Refresh Rate Technology

Distinguish panel capability, traditional mode switching, and Android ARR. An LTPO panel specification does not guarantee a particular rate range or AOSP ARR support.

AOSP introduced ARR in Android 15, requiring panel, kernel, system, and composer3 v3 support. Refresh cadence can change within one display mode. TE/Vsync may differ from refresh rate: the official example uses 240 Hz timing with a 120 Hz maximum refresh rate. The app guide specifies Android 15 QPR1+ with the required HAL. Neither an OS version nor “120 Hz/LTPO” alone establishes support.

Surface.setFrameRate(float, int) is available from Android 11 (API 30). It hints at a Surface’s intended content frame rate; it does not force a display mode or throttle rendering. This game-content example assumes an app-owned, valid display Surface and compile SDK 30+:

1
2
3

if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.R) {
    surface.setFrameRate(60.0f, Surface.FRAME_RATE_COMPATIBILITY_DEFAULT);
}

The example’s 60 FPS is a content target, not guaranteed 60 Hz display or automatic 60 FPS rendering. Android 16 (API 36) adds FRAME_RATE_COMPATIBILITY_AT_LEAST for UI/scrolling hints requesting at least a given rate. Games keep DEFAULT; fixed-rate video uses FRAME_RATE_COMPATIBILITY_FIXED_SOURCE. Use constants only on their supported API versions; set frameRate to 0 when the hint is no longer needed. See the Surface API.

Other surfaces, display capabilities, and power policy affect selection; a multiple of the requested rate may be chosen. Keep animation time-based and work correctly when the hint is not adopted. See the frame-rate guide.

Advantages and Challenges of 120Hz

Experience Improvements Brought by 120Hz

When I got my first 120 Hz phone, these were the changes I noticed:

Everything becomes smoother: From desktop sliding, application switching to browsing Weibo, screen updates are more frequent, and content follows finger movement more accurately. That was my impression when scrolling Moments or Weibo. Attributing it to refresh rate alone would require controlling app frame rate, motion, and display mode on the same device.
Game experience can improve: When playing Honor of Kings and 和平精英 at the time, I felt that the controls were easier to use. If a game produces frames steadily and the display uses a matching mode, there are more opportunities to show new actions. “Seeing an action 8ms earlier” is not a fixed gain; input, rendering, and display latency must be measured.
Reading comfort is personal: I find 120 Hz more comfortable while reading and scrolling for long periods. This is an impression, not a controlled comparison or a visual-health conclusion.
Touch and display are separate: A 120Hz display mode does not by itself show that the touch sampling rate increased; check the two specifications separately.

Practical Problems Faced by 120Hz

Of course, high refresh screens also bring a series of technical challenges:

Power consumption problem: A higher refresh mode may increase display and rendering power. The effect needs a same-device test with brightness, app workload, duration, and measurement method held constant; there is no universal 15-20% increase.
Tighter frame cadence: An app targeting stable 120FPS produces a frame about every 8.33ms, but its precise deadline depends on device scheduling, reflected in FrameTimeline predictions; the entire rendering pipeline is not one serial 8.33ms task.
Temperature: Sustained high-frame-rate gaming can increase CPU/GPU/display work and lead to thermal throttling. Separate refresh-rate effects from game workload through same-device, same-scene measurements.
Application target frame rate: A 60FPS app on a 120Hz display is not necessarily an adaptation failure; video, static content, or power policy may intentionally use a lower rate.

Thoughts and Future Outlook

On-Demand Adjustment: Intelligent Management of Refresh Rate from ProMotion

Do we need to stay at 120 Hz in every situation? Static pages and fast scrolling need different update rates. Apple’s ProMotion guide provides content-based animation hints:

iOS Promotion Animation Recommended Frame Rate

High-impact motion: fullscreen transitions may request CAFrameRateRange(minimum:80, maximum:120, preferred:120); use high rates selectively.
Opacity/color changes and small movements: use CAFrameRateRange.default.
Slow, small animations: examples span 8–15, 15–24, or 30–48, with preferred=0. These ranges do not guarantee every integer hardware rate.
Other cases: use the default range.

These are iOS 15+ API suggestions, not fixed system rules or Android settings. Requests are not guaranteed; custom iPhone animations requesting above 60 Hz also need the documented CADisableMinimumFrameDurationOnPhone configuration. Lower update frequency can reduce rendering work, while display power still depends on hardware and actual refresh behavior.

Trade-off Between Power and Experience

Reducing refresh rate from 120Hz to 60Hz may save power, but the amount depends on the device, brightness, content, and actual app frame rate. A universal 10-15% saving cannot be inferred without a controlled measurement.

High refresh rates help most with scrolling, animation, and other interactions that need quick feedback. For static content, the system can choose a lower mode, provided the transition does not introduce visible judder.

Developer’s Adaptation Strategy

For surfaces your app manages, hint at the content rate and pace production accordingly. Ordinary View animations follow framework scheduling; this example is for an app-managed Surface. ARR device requirements are described above.

Record active mode/refresh cadence, produced and presented frame intervals, input-to-feedback latency, and power-test conditions. “Supports 120 Hz” alone does not establish an improvement.

Conclusion

When I wrote this in 2025, I felt that 120 Hz had noticeably improved phone interaction. My expectation was that it could remain common for a long time, with more effort going into choosing the right rate for each situation. That was a personal forecast, not a standard every device must meet.

For developers, tools like Perfetto help inspect performance problems under 120Hz. The nominal refresh interval changes from about 16.67ms to 8.33ms, but sustained 120FPS still depends on the app workload, device, thermal state, GPU, and presentation timing; avoiding main-thread blocking alone does not guarantee it.

In Perfetto, check the active display mode and compare the app and SurfaceFlinger timelines to distinguish late app work, late presentation, and intentionally lower-rate content. Power claims need separate measurements on the same device, at the same brightness, in the same scene.

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!