Chrome does not use GPU acceleration in Docker — causes video playback lag and tab crashes

[linborulinboru]

Description:
Chrome inside Docker does not use GPU hardware acceleration for rendering or video
decode — everything falls back to software (CPU), causing video playback to be very
slow and choppy.

Checked chrome://gpu inside a session: GPU Rasterization and Video Decode both
report "Software only", renderer is SwiftShader/SwANGLE.

Additionally, during video playback, the browser tab crashes intermittently and
redirects back to the Profile page without warning. This appears to be caused by
the heavy CPU load from software rendering — the Chrome renderer process runs out of
resources and is killed.

Expected: Chrome uses GPU hardware rasterization and hardware video decode when a
GPU is available in the container, keeping the renderer stable during video playback.

---

CloakBrowser version: latest (Docker image built from repo)

Wrapper: Python

Environment: Docker, Linux (Debian Bookworm), amd64, NVIDIA GPU with
nvidia-container-toolkit

Launch options: Default, no extra flags.

Tested with a different IP or proxy? No — unrelated to proxy.

Works outside Docker / on host machine? Not tested.

---

Steps to reproduce:

1. Run docker compose up with an NVIDIA GPU available
2. Open a browser session and navigate to any video site
3. Check chrome://gpu — all GPU features show Software only
4. Video playback is choppy with high CPU usage
5. After a short time, the tab crashes and redirects back to the Profile page

---

Additional notes:

There are two gaps preventing GPU acceleration:

1. No GPU flags passed to Chrome. build_args() only includes
   --ignore-gpu-blocklist. Flags like --use-gl=egl,
   --enable-gpu-rasterization, and --enable-features=VaapiVideoDecoder
   are never set.

2. The cloakbrowser service has no GPU access in docker-compose.yml.
   Only cloakbrowser-manager has a GPU reservation — but Chrome actually
   runs inside the cloakbrowser container.

The tab crash and redirect to Profile page is a direct consequence of the software
rendering overload. Enabling GPU acceleration should resolve both the performance
and the stability issue.

Would love to see an opt-in env var (e.g. CLOAKBROWSER_GPU_ACCEL=1) that
enables GPU acceleration when the container has GPU access. Thanks!

[Cloak-HQ]

Thanks for the detailed report and clear reproduction steps.

You're right on both gaps. Let me confirm what's happening:

1. Chrome flags: build_args() only adds --ignore-gpu-blocklist (in headed mode), which lets SwiftShader serve WebGL — it doesn't enable hardware GPU acceleration. Flags like --use-gl=egl, --enable-gpu-rasterization, and --enable-features=VaapiVideoDecoder are not passed.

2. Docker Compose: Neither container currently has GPU reservations configured.

The tab crashes you're seeing are consistent with software rendering overload — the Chromium renderer process gets OOM-killed under heavy CPU decode.

One thing to be aware of: enabling real GPU changes the WebGL renderer string from SwiftShader/SwANGLE to your actual GPU (e.g. "NVIDIA GeForce RTX 3070"). If you're using fingerprint spoofing, make sure your gpu_vendor / gpu_renderer profile settings match what Chrome actually reports with hardware acceleration on — otherwise the mismatch between the spoofed string and the real rendering behavior becomes a detection signal.

We'll look into adding opt-in GPU support — an env var like CLOAKBROWSER_GPU_ACCEL=1 that injects the right Chrome flags and documents the docker-compose GPU reservation setup. This needs to stay opt-in since most deployments run without a GPU and the fingerprint implications need to be explicit.

[mvanhorn]

Implemented in #229 — opt-in via CLOAKBROWSER_GPU_ACCEL=1 or gpu_accel=True (Python) / gpuAccel: true (JS). VaapiVideoDecoder is Linux-gated. Defaults unchanged. Example docker-compose under examples/docker-compose.gpu.yml.

[WuNein]

Any update? Most sites with videos are causing serious CPU usgae.