protonscr

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

steamopen overlayWeb Component
ValveSoftware/steam-for-linux#13513 · opened 2026-08-13 by doombadroid · updated 2026-08-13 · 0 comments · github
Ddoombadroid 2026-08-13 github

Your system information

  • Steam client version (build number): 1785799196
  • Distribution: Gentoo (Hyprland/Wayland session; Steam under XWayland)
  • Kernel: 7.1.3 (custom, CachyOS-patch-based)
  • GPU: AMD Radeon 8060S (Strix Halo, gfx1151), Mesa 26.1.5, RADV/radeonsi
  • steamwebhelper CEF: Chromium 126.0.6478.183
  • Opted into Steam client beta: no
  • Have you checked for system updates: yes

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:

  1. Enable GPU accelerated rendering in web views; restart Steam.
  2. 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).
  3. Open the overlay (Shift+Tab) and any overlay web page.
  4. Overlay web content updates at ~1 FPS. The game itself is unaffected.
  5. 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.

Proton versions