How Chromium Implements PiP with Aura and Views

This article explores the technical implementation of the Picture-in-Picture (PiP) feature within the Chromium web browser, focusing specifically on how it achieves an always-on-top video window. It breaks down the roles of Chromium's custom UI framework, Views, and its hardware-accelerated window manager, Aura. By examining the journey from the browser process to the operating system's native windowing system, you will understand the precise mechanisms that keep floating video players persistently visible above other applications.

Initiating the Picture-in-Picture Window

When a user triggers Picture-in-Picture on a video element, the Blink rendering engine communicates this request to the browser process via Inter-Process Communication (IPC). The browser process responds by instantiating the VideoPictureInPictureWindowControllerImpl class. This controller manages the lifecycle of the PiP session and is responsible for spawning the actual floating window that the user sees on their screen.

Constructing the UI with the Views Framework

Chromium does not use standard operating system UI controls for its interface; instead, it uses an internal cross-platform UI framework called Views. To create the PiP window, the controller instantiates VideoOverlayWindowViews, which inherits from views::Widget.

To ensure the PiP window looks like a modern floating player and stays on top of other windows, VideoOverlayWindowViews configures a views::Widget::InitParams struct during initialization:

  • Frameless Design: It sets the widget type to TYPE_WINDOW_FRAMELESS, removing the standard OS title bar and borders.
  • Always-on-Top State: It sets the z_order property to ui::ZOrderLevel::kFloatingWindow. In Chromium's Views architecture, this specific enumeration is the cross-platform instruction that designates a widget as an always-on-top surface.
  • Custom Controls: Views builds a hierarchy of views::View objects inside the widget to render custom overlay controls, such as the play/pause toggle, the close button, and resize handles, which appear only when the user hovers over the window.

Bridging Views to the OS via Aura

On Windows, Linux, and ChromeOS, the Views framework relies on Aura, Chromium's hardware-accelerated window manager. In the Aura architecture, every UI surface is represented as an aura::Window instance. However, a standard aura::Window only exists inside the main browser window. Because a PiP window must float independently on the user's desktop, even if the main browser is minimized, it requires a special bridge.

Chromium achieves this by backing the PiP views::Widget with a DesktopNativeWidgetAura. This class pairs the internal aura::Window with a DesktopWindowTreeHost. The DesktopWindowTreeHost is the crucial component that translates Aura's abstract window properties into native operating system windowing calls.

Enforcing the Always-on-Top Property Natively

Once the DesktopWindowTreeHost is initialized with the ui::ZOrderLevel::kFloatingWindow parameter from Views, it instructs the underlying operating system to lock the window to the top of the Z-order stack:

  • Windows: DesktopWindowTreeHostWin translates the floating window parameter into the Win32 API extended window style WS_EX_TOPMOST. It applies this using the SetWindowPos function, passing the HWND_TOPMOST flag to the Windows Desktop Window Manager (DWM).
  • Linux (X11/Wayland): Using Chromium's Ozone platform abstraction layer, DesktopWindowTreeHostPlatform communicates with the Linux display server. On X11, it sets the _NET_WM_STATE_ABOVE window property. On Wayland, it utilizes specific compositor protocols (where supported) to request top-level floating status.
  • ChromeOS: Because Aura is the native window manager on ChromeOS (known as Ash), no OS translation is needed. The PiP aura::Window is simply parented directly to a dedicated always-on-top container (kShellWindowId_PipContainer) within the Ash root window hierarchy.

Rendering the Video Stream

An always-on-top Aura window is just an empty shell without the video content. Every aura::Window is backed by a ui::Layer for hardware-accelerated compositing. VideoOverlayWindowViews creates a layer tree where a dedicated video ui::Layer sits beneath the UI control layers.

Instead of copying video frames from the web page to the PiP window, Chromium uses its Viz display compositor. The PiP window's video layer is assigned a viz::SurfaceId. The renderer process decodes the video stream and submits the frames directly to the Viz compositor using this SurfaceId. Viz then composites the video frames directly into the Aura window's layer, resulting in smooth, hardware-accelerated playback that remains decoupled from the main browser window's rendering pipeline.