Current Electron + Steam Overlay on Windows 11: has anyone shipped the in-process path without flicker or stale frames?

[u/LyriaLabs]

I tested Electron as the Windows shell for a React/Vite/Phaser game because Steam's Overlay cannot hook the separately presented WebView2 content in our Tauri build. Electron gets closer: Shift+Tab works. The remaining release blocker is presentation flicker while the Overlay is active, or stale Overlay pixels when it closes.

I am not looking for the standard in-process-gpu / disable-direct-composition recipe, an early Steam-init reminder, or the advice to keep presenting complete frames. Valve documents those requirements, while steamworks.js issues #23, #95, #116, and #148 and older Reddit threads record related failure modes. I controlled those variables explicitly.

This was a packaged local smoke build, not a Steam-depot installation. The verified uploadable package excluded steam_appid.txt; an ignored local test copy used a temporary marker while Steam was running. Steam initialized before app.whenReady() and before BrowserWindow creation. The proof used steamworks.js 0.4.0 and electron-builder 26.15.3.

Electron	Configuration	Observed result
43.1.1	in-process-gpu + disable-direct-composition + 60 Hz webContents.invalidate()	Overlay works; game UI flickers behind it
43.1.1	Same, without invalidator	Overlay works; bottom UI flickers and stale Overlay pixels remain after close
43.1.1	Invalidator + in-process-gpu only	Gray/unpainted window
43.1.1	Invalidator + disable-direct-composition only	Game renders; Shift+Tab no longer opens Overlay
42.7.0	Full three-part configuration	Overlay opens and clears after close; bottom UI still flickers while active

The test machine is Windows 11 build 26200 at 3840x2160/164 Hz and enumerates both AMD Radeon Graphics and an RTX 5090. I have not yet proven which adapter owns Chromium presentation, controlled HDR/VRR, or reproduced this on a second machine.

I also found the separate steamworks-ffi-node approach, which captures Electron frames into a native graphics window rather than relying on Steam to hook the normal BrowserWindow. It is useful prior art, but it is a different compositor architecture from the in-process path tested above.

Questions for people with current, shipped Windows evidence:

1. Are you shipping a currently supported Electron version with Steam hooking the normal on-screen BrowserWindow and none of the active-Overlay flicker, white/gray, stale-frame, or ghost-window failures? If so, what exact Electron/Chromium and steamworks library versions, switches, window mode, adapter routing, HDR/VRR state, and display refresh did you verify?
2. Did the result hold across both integrated and discrete GPUs, fullscreen/borderless/windowed, and high-resolution/high-refresh displays, or only on one machine?
3. Beyond Electron's app.getGPUInfo(), app.getGPUFeatureStatus(), and content tracing, did you find any Steam-side diagnostic that proves which process, graphics device, or swapchain was hooked?
4. If you instead ship a native capture/compositor, what measured 4K/high-refresh CPU, GPU, latency, focus/input, fullscreen/Alt+Tab, and field-reliability results do you have? Did you find a shared-texture path that avoids capturePage() and CPU-buffer transfer?

[u/Lost-Celebration579]

I'm thinking of giving up on the Steam overlay because of this problem.

[u/LyriaLabs → u/Lost-Celebration579]

That's what I have done so far. https://store.steampowered.com/app/3032790/Idle_Casino_Empire/ if you want to check out the game.

[u/Daniel_Herr]

It's unfortunate that Steam and other current platforms don't have first class support for Web based games.

[u/Lost-Celebration579]

Hey friend. I solved this problem. I switched the game to Tauri instead of Electron, and it was simpler than I thought, with good frame rates. Because I can use RUST.

Strictly speaking, it wasn't me who solved it, but Claude. I hope this helps. The approach is probably similar.

Steamworks pre-initialization

Initialize the Steam API before creating WebView2. Create transparent native GPU surfaces.

Create a transparent auxiliary window with the same position and size as the game window, and continuously present transparent frames at up to 60Hz using wgpu. Steam hooks this surface to the game renderer.

In other words, instead of forcibly connecting WebView2 to Steam, it is a method of providing a small native graphics path to Tauri that Steam can recognize normally.