How SurfaceFlinger Renders Chromium Frames on Android

This article provides an overview of the critical role Android's SurfaceFlinger system service plays in displaying web content from the Chromium browser onto a device's screen. It examines the pipeline of how Chromium generates composited frames, passes those graphics buffers to the operating system, and how SurfaceFlinger ultimately combines them with other system elements for final hardware presentation.

Understanding the Two Compositors

To understand how a webpage ends up on an Android screen, it is necessary to distinguish between two different compositors: Chromium's internal compositor and Android's system compositor, known as SurfaceFlinger.

Chromium does the heavy lifting of rendering the webpage itself. It takes HTML, CSS, JavaScript, videos, and WebGL canvases, breaks them into layers, and uses its own GPU process (specifically the Viz display compositor) to combine them into a single frame. However, Chromium cannot push this frame directly to the physical screen, because the browser shares the display with Android system elements like the status bar and navigation bar. This is where SurfaceFlinger steps in.

The Producer-Consumer Relationship

SurfaceFlinger is a system-wide service that accepts buffers of graphical data from multiple sources, composites them, and sends them to the display hardware. In the Android architecture, this relies on a producer-consumer model facilitated by a mechanism called a BufferQueue.

1. The Producer (Chromium): Android provides Chromium with a Surface (backed by an ANativeWindow in C++). When Chromium finishes rendering a webpage frame, it writes the pixel data into a graphics buffer and queues it into the BufferQueue associated with that Surface.
2. The Consumer (SurfaceFlinger): SurfaceFlinger acts as the consumer at the other end of the BufferQueue. When Chromium queues a completed frame, SurfaceFlinger is notified that a new buffer is ready to be acquired.

VSYNC and Frame Latching

SurfaceFlinger does not process Chromium's frames the exact microsecond they are queued. Instead, the entire pipeline is regulated by the display's hardware refresh rate, managed via VSYNC (Vertical Synchronization) signals.

When a VSYNC signal occurs, SurfaceFlinger wakes up to prepare the next screen update. It inspects the BufferQueue connected to Chromium. If Chromium has finished rendering and queued a new buffer in time, SurfaceFlinger "latches" onto this buffer, locking it so it can be read safely. While SurfaceFlinger reads this buffer, Chromium is handed a different, empty buffer from the queue so it can immediately begin drawing the next frame without waiting.

Hardware Composition and Display

Once SurfaceFlinger has latched onto the latest frame from Chromium, it must combine it with other visible Android layers, such as the top notification shade, the bottom gesture bar, or an on-screen keyboard.

Rather than using the GPU to merge these layers into a single image—which drains battery and consumes bandwidth—SurfaceFlinger delegates the task to the Hardware Composer (HWC) HAL (Hardware Abstraction Layer).

SurfaceFlinger passes the list of layers, including the Chromium buffer, to the HWC. The HWC uses dedicated display processor hardware to overlay the system UI on top of the Chromium frame on the fly as pixels are sent to the physical screen. Once the frame is presented and the next VSYNC signal hits, SurfaceFlinger releases the old buffer back to the BufferQueue, allowing Chromium to reuse it for future frames.

Direct Composition and Overlays

In scenarios where Chromium is playing a video or running high-performance content, it may send multiple buffers to SurfaceFlinger instead of just one. Using Android's SurfaceControl API, Chromium can pass the video layer and the UI layer separately. SurfaceFlinger then instructs the Hardware Composer to composite the video directly at the hardware level, bypassing Chromium's internal compositor entirely to save power and ensure smoother playback.