Chromium's Composited UI for Android Tab Animations

This article explores the specialized composited user interface architecture that enables the Chromium web browser on Android to render and animate tab switcher cards at consistently high frame rates. It breaks down how Chromium bypasses standard Android UI rendering bottlenecks by leveraging a dedicated C++ browser compositor, hardware-accelerated texture caching, and a split Java-C++ layout engine to achieve smooth, jank-free transitions.

Bypassing the Standard Android View System

Standard Android UI elements are built using the View hierarchy. While effective for standard application interfaces, the traditional Android View system struggles when animating dozens of high-resolution web page previews simultaneously. Allocating, resizing, and drawing large bitmaps on the Android UI thread often triggers garbage collection pauses and missed frame deadlines, resulting in animation stutter.

To solve this, Chromium uses a custom Composited UI Architecture. Instead of relying on Android's Canvas to draw the tab switcher, Chromium delegates the rendering to its own internal C++ compositor engine, rendering the UI directly to an Android SurfaceView or TextureView using OpenGL or Vulkan.

The Browser Compositor

At the core of this architecture is the Browser Compositor. While Chromium uses a compositor inside each renderer process to draw web pages, it also runs a separate instance of the compositor (cc::LayerTreeHost) inside the main browser process.

This Browser Compositor is responsible for uniting the web content with the browser’s surrounding UI (such as the toolbar and tab switcher) into a single composited frame. Because it operates directly with the GPU, it can apply complex transformations—such as scaling, translating, and fading tab cards—at 60, 90, or 120 frames per second with minimal CPU overhead.

LayoutManager and SceneLayers

The architecture divides responsibilities between Java (for UI logic and gesture handling) and C++ (for rendering and composition).

  • LayoutManager (Java): This component drives the state of the UI. When a user opens the tab switcher or flings through tab cards, the LayoutManager processes the touch events and calculates the exact position, scale, and opacity of every tab card for the current frame. It represents each tab as a lightweight virtual view called a LayoutTab.
  • SceneLayer (C++): Once Java calculates the positions for a frame, it pushes these properties across the Java Native Interface (JNI) to a C++ SceneLayer (specifically, a TabListSceneLayer). The SceneLayer translates these properties into nodes within the Chromium compositor’s layer tree (cc::Layer), instructing the GPU where to draw the textures on the screen.

By keeping the layout math in lightweight Java objects and the actual drawing in C++, Chromium avoids the expensive layout and measure passes of the native Android View system.

TabContentManager and Texture Compression

Animating tab cards requires immediate access to visual snapshots of the user's open web pages. The TabContentManager is the C++ subsystem responsible for capturing, compressing, and caching these snapshots.

  1. Live Layers: If a tab is currently active and its renderer process is alive in memory, the compositor can grab the live cc::SurfaceLayer directly from the renderer and scale it down into a tab card.
  2. ETC1 Compressed Textures: For background tabs whose renderers have been killed to save memory, the TabContentManager captures a snapshot of the page before it closes. It compresses this snapshot into an ETC1 texture—a format that GPUs can read directly without decompression.
  3. In-Memory Caching: When the user opens the tab switcher, these compressed textures are streamed straight into GPU memory, allowing the compositor to draw dozens of high-resolution tab previews instantly without stalling the main thread.

ResourceManager and Hybrid UI

A tab card is not just a web page preview; it also contains standard UI elements like the website favicon, the page title, and a close button. Drawing text and vector icons directly in C++ OpenGL is complex, so Chromium uses a hybrid approach managed by the ResourceManager.

Chromium renders the tab card's header (title, favicon, close button) using standard Android View components off-screen. A ViewResourceAdapter captures this Android View as a single bitmap and uploads it to the GPU via the ResourceManager. Once uploaded as a texture resource, the C++ compositor attaches it to the top of the tab's SceneLayer. The text and icons only need to be redrawn by Android if the tab's title changes; otherwise, the GPU simply moves the cached texture around the screen alongside the tab thumbnail.

The Modern Grid Tab Switcher

In newer versions of Chromium, the browser introduced the Grid Tab Switcher, which utilizes a standard Android RecyclerView for the grid layout. However, to maintain high frame rates during the critical zoom-in and zoom-out animations (transitioning from a fullscreen webpage to a small card in the grid), Chromium still relies on the Composited UI Architecture.

When the transition animation begins, the Android RecyclerView is hidden, and the C++ Browser Compositor takes over. It animates the live web page SceneLayer shrinking down to the exact coordinates of the grid card. Only after the high-speed animation finishes does Chromium swap the composited layer out and reveal the underlying Android RecyclerView for standard scrolling.