In-game overlay & game web views drop to ~1 FPS whenever the GPU is busy: Linux CEF has no native GpuMemoryBuffers, so every overlay frame does a GPU readback
steamopenoverlayWeb Component
ValveSoftware/steam-for-linux#13513 ·
opened 2026-08-13
by doombadroid ·
updated 2026-08-13 ·
0 comments ·
github
Please describe your issue in as much detail as possible:
Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist
With "Enable GPU accelerated rendering in web views" ON, every CEF surface
that is delivered into a running game the Shift+Tab overlay browser and Steam Overlay served in-game web views, renders at roughly 1 FPS whenever
the game keeps the GPU busy. The Steam client's own windows (library, store)
stay perfectly smooth at the same moment.
With the setting OFF, the overlay browser and in-game web views are
immediately smooth in the same scenario, at the cost of software rendering for
the whole client.
I believe this is not a driver bug: Chromium/CEF on Linux-X11 ships with
native (dmabuf-backed) GpuMemoryBuffers compiled out, so any surface that has
to cross processes falls back to a copy path that synchronizes against a
saturated GPU queue once per frame. Details and the experiments that support
this are below.
Steps for reproducing this issue:
Enable GPU accelerated rendering in web views; restart Steam.
Run any game that keeps GPU utilization near 100%
(tested: Arma 3 via GE-Proton10-34 inside nested gamescope with FSR
upscaling + frame generation, gpu_busy_percent steady at 95–97%;
the mechanism below is not gamescope-specific).
Open the overlay (Shift+Tab) and any overlay web page.
Overlay web content updates at ~1 FPS. The game itself is unaffected.
Alt-tab to the Steam library window: smooth. That differential
same steamwebhelper, same GPU process, same moment is the tell.
Diagnosis
webhelper_gpu.txt (fresh dump, 2026-08-12) reports hardware GL
(ANGLE/AMD) with every feature "enabled", but every GpuMemoryBuffer format
is software-only:
[ gpuMemoryBufferInfo ]:
[ R_8 ]: Software only
[ RG_88 ]: Software only
[ RGBA_8888 ]: Software only
[ BGRA_8888 ]: Software only
... (all 17 formats: Software only)
To rule out "flag just not set", I injected --enable-native-gpu-memory-buffers --enable-zero-copy into steamwebhelper
(verified present in /proc/<pid>/cmdline of the running browser process) and
re-dumped: the table is unchanged. That switch has been a no-op on desktop
Linux for years native GpuMemoryBuffer support is compiled out for the X11
platform (upstream: crbug.com/552068; ui/gfx/linux/client_native_pixmap_dmabuf.cc
is only wired up for ChromeOS/Ozone-GBM configurations).
Consequences for the overlay path:
Client-owned windows composite inside the CEF GPU process and never leave
it > smooth regardless of game load.
Overlay / in-game views must be exported cross-process to reach the game's
swapchain. With no native GMB, that export degrades to a GPU>CPU copy
(readback) once per frame.
A readback is a pipeline sync. When the game keeps the ring at ~96% with
multiple frames in flight, each sync waits behind the full queued workload,
and a CEF frame needs several such round-trips > observed ~1 FPS.
With web view GPU acceleration disabled, CEF rasterizes in system memory,
the export is a plain memcpy, nothing ever waits on the GPU > smooth even
at 100% GPU load.
So the current setting is effectively backwards on saturated-GPU machines
(common case: iGPU handhelds/APUs, frame generation, gamescope upscaling):
"GPU accelerated" web views are the slow path exactly when a game is running,
which is the only time the overlay matters.
Suggested fixes
Ship steamwebhelper with a working native-buffer path on Linux
(Ozone/Wayland or GBM/minigbm), so overlay surfaces can be exported
zero-copy as dmabufs; or
Special-case the overlay pipeline to avoid per-frame GPU readback
(software raster for exported views is already proven fine that is what
the OFF setting does today, just globally); or
At minimum: detect the situation (X11 CEF + game running + GMB
software-only) and stop defaulting overlay views onto the readback path,
or document that users with GPU-bound games should disable the setting.
Workaround for anyone else hitting this
Steam > Settings > Interface > uncheck "Enable GPU accelerated rendering in
web views" > restart Steam. Overlay browser and in-game web views become
smooth immediately; the client UI falls back to software rendering.
Your system information
Please describe your issue in as much detail as possible:
Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist
With "Enable GPU accelerated rendering in web views" ON, every CEF surface
that is delivered into a running game the Shift+Tab overlay browser and
Steam Overlayserved in-game web views, renders at roughly 1 FPS wheneverthe game keeps the GPU busy. The Steam client's own windows (library, store)
stay perfectly smooth at the same moment.
With the setting OFF, the overlay browser and in-game web views are
immediately smooth in the same scenario, at the cost of software rendering for
the whole client.
I believe this is not a driver bug: Chromium/CEF on Linux-X11 ships with
native (dmabuf-backed) GpuMemoryBuffers compiled out, so any surface that has
to cross processes falls back to a copy path that synchronizes against a
saturated GPU queue once per frame. Details and the experiments that support
this are below.
Steps for reproducing this issue:
(tested: Arma 3 via GE-Proton10-34 inside nested gamescope with FSR
upscaling + frame generation,
gpu_busy_percentsteady at 95–97%;the mechanism below is not gamescope-specific).
same steamwebhelper, same GPU process, same moment is the tell.
Diagnosis
webhelper_gpu.txt(fresh dump, 2026-08-12) reports hardware GL(ANGLE/AMD) with every feature "enabled", but every GpuMemoryBuffer format
is software-only:
To rule out "flag just not set", I injected
--enable-native-gpu-memory-buffers --enable-zero-copyinto steamwebhelper(verified present in
/proc/<pid>/cmdlineof the running browser process) andre-dumped: the table is unchanged. That switch has been a no-op on desktop
Linux for years native GpuMemoryBuffer support is compiled out for the X11
platform (upstream: crbug.com/552068;
ui/gfx/linux/client_native_pixmap_dmabuf.ccis only wired up for ChromeOS/Ozone-GBM configurations).
Consequences for the overlay path:
it > smooth regardless of game load.
swapchain. With no native GMB, that export degrades to a GPU>CPU copy
(readback) once per frame.
multiple frames in flight, each sync waits behind the full queued workload,
and a CEF frame needs several such round-trips > observed ~1 FPS.
the export is a plain memcpy, nothing ever waits on the GPU > smooth even
at 100% GPU load.
So the current setting is effectively backwards on saturated-GPU machines
(common case: iGPU handhelds/APUs, frame generation, gamescope upscaling):
"GPU accelerated" web views are the slow path exactly when a game is running,
which is the only time the overlay matters.
Suggested fixes
(Ozone/Wayland or GBM/minigbm), so overlay surfaces can be exported
zero-copy as dmabufs; or
(software raster for exported views is already proven fine that is what
the OFF setting does today, just globally); or
software-only) and stop defaulting overlay views onto the readback path,
or document that users with GPU-bound games should disable the setting.
Workaround for anyone else hitting this
Steam > Settings > Interface > uncheck "Enable GPU accelerated rendering in
web views" > restart Steam. Overlay browser and in-game web views become
smooth immediately; the client UI falls back to software rendering.