How a Headless Chromium GPU Fix Took an AI Avatar Stream From 4fps to 58fps

A developer building an always-on AI avatar streaming service has documented on dev.to how headless Chromium was silently ignoring the GPU and rendering a 3D avatar at around 4fps — and how a three-part configuration fix raised the same scene to 57–58fps. The writeup, originally published in Japanese at forge.workstyle.tech, describes a pipeline that renders a VRM 3D model in headless Chromium, captures the video, and streams it over RTMP, with the avatar speaking and reacting to comments without human intervention.

The CPU-only design collapsed on the real workload

The original design avoided GPUs entirely, for cost and scalability reasons. Chromium ships SwiftShader, a CPU-based WebGL implementation, and a simple triangle test ran at a full 60fps — which the author describes as a false sense of security. The actual VRM avatar scene dropped to roughly 4fps on the same browser, CPU and resolution, about 15 times slower than the toy benchmark.

A five-minute resolution sweep located the bottleneck

Facing the slowdown, the author swept output resolution and measured framerates: 720p, 540p and 360p all delivered about 4fps. Since cutting the pixel count made no difference, the bottleneck was not fragment processing but geometry and CPU work — per-bone skinning transforms, spring-bone physics simulation for hair and clothing running on the CPU every frame, and the extra outline passes of MToon toon shading adding draw calls. None of these scale with output resolution.

That finding invalidated the design document's fallback plan of dropping to 540p at 24fps. The author's stated lesson: a fallback plan should always specify what is being reduced and what that reduction is proportional to, otherwise it is a wish rather than a plan. Faced with the alternatives of lower framerates or a simplified model, the author opted to rent RTX-class GPU cloud instances.

Three conditions before Chromium renders on GPU

Even with a GPU assigned to the container, nvidia-smi working, and a WebGL context created, Chromium still fell back to SwiftShader without any error or warning. According to the post, GPU rendering only happens when all three of the following are in place:

• A full build of Chromium, not the lightweight headless shell that programmatic launchers often start by default. The shell suits CI DOM testing but lacks the GPU rendering path.
• EGL ICD registration — JSON files such as 10_nvidia. under /usr/share/glvnd/egl_vendor.d/ and Vulkan ICD files under /usr/share/vulkan/icd.d/ — plus libglvnd. In containers, NVIDIA_DRIVER_CAPABILITIES must be set to all, since the default of compute,utility leaves graphics libraries unmounted.
• Launch flags: --use-gl=angle, --use-angle=vulkan (or gl-egl), --ignore-gpu-blocklist and --no-sandbox. The blocklist flag matters because Chromium otherwise disqualifies driver setups it considers known-problematic, which the author says is nearly always the case in containerized environments.

Verify the renderer instead of trusting a clean launch

The post emphasises that this stack reports success when it has actually failed: pages load and contexts are created while everything runs on the CPU. The reliable check is reading GL_RENDERER from inside the page via the WEBGL_debug_renderer_info extension — a SwiftShader string means fallback, while the NVIDIA adapter name confirms GPU rendering. The author wired this logging into startup so the pipeline verifies itself automatically.

ANGLE backends and frame capture quirks

The two ANGLE backends were not equivalent. Both gl-egl and vulkan produced the same 57–58fps, but image quality differed between them, and the author settled on vulkan. Frame capture broke in its own way: canvas.captureStream(), which worked under CPU rendering, produced broken or black output once rendering moved to the GPU. The recommended replacement is Page.startScreencast from the Chrome DevTools Protocol.

Why it matters

Headless browsers in containers are now standard infrastructure for testing, scraping, rendering and automation, and this post is a compact catalogue of how GPU acceleration fails quietly in that environment — no errors, normal-looking metrics, and contexts that succeed on the wrong device. The performance stakes are not marginal: 4fps versus 58fps is the gap between unusable and shippable for real-time 3D. The debugging methods travel well beyond live streaming. Measure framerate against resolution to identify whether the bottleneck is pixel fill or geometry and CPU work, read GL_RENDERER to confirm which hardware actually drew the frame, and treat container GPU access as unproven until the renderer string says otherwise.