WebView2 leaks GDI objects on GlazeWM workspace switch

[johnsideserf]

Description

WebView2 widget windows leak GDI objects every time a GlazeWM workspace switch occurs. Each switch leaks ~100-200 GDI objects per switch (with 2 widgets active). Over extended use with frequent workspace switching, this causes system-wide cursor stutter and UI lag as the process approaches the Windows per-process GDI limit (10,000).

Evidence

GDI object count was monitored using GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS) via a PowerShell script sampling every 30 seconds.

Baseline (no workspace switching)

GDI count stable at 30-36 for 30+ minutes:

00:36:11 | gdi=36
00:42:49 | gdi=36  (stable)

During workspace switching

Each GlazeWM workspace switch causes a GDI spike:

00:55:19 | gdi=1243
00:55:49 | gdi=1359  (+116, after switch)
00:56:49 | gdi=1468  (+109, after switch)
01:04:50 | gdi=1481  (stable between switches)
01:05:20 | gdi=1573  (+92, after switch)
01:06:50 | gdi=1802  (+218, after switch)
01:07:20 | gdi=1808  (stable after switch)

Key observations

• Each workspace switch leaks ~100-200 GDI objects (with 2 widget windows)
• GDI count never decreases — objects are never released
• Ctrl+Alt+Delete (secure desktop switch) does NOT cause the leak — only GlazeWM workspace switches
• Widgets are configured with visible_on_all_workspaces(true)

Instrumentation ruling out Zebar's Rust code

GDI counting instrumentation was added around three suspected code paths:

1. icon_to_image() in systray-util (systray icon bitmap conversion)
2. Systray::on_event() (systray event handler)
3. Systray provider emission (PNG encoding + Tauri event emit)

Result: zero GDI delta logged across all three paths. The leak is entirely within the WebView2/Tauri window management layer, triggered by whatever window events GlazeWM sends during workspace switches.

Reproduction

1. Run Zebar with 2+ widget windows and GlazeWM
2. Monitor GDI objects: GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)
3. Switch GlazeWM workspaces repeatedly
4. Observe GDI count climbing ~100-200 per switch

Environment

• Windows 11
• GlazeWM (latest)
• Zebar with visible_on_all_workspaces: true widgets
• WebView2 (via Tauri 2.x / WRY)

Possible causes

Since widgets use visible_on_all_workspaces(true), GlazeWM may still be sending window management messages (z-order changes, WM_WINDOWPOSCHANGED, etc.) to widget windows during workspace switches. WebView2 appears to allocate GDI resources (device contexts, bitmaps) in response to these messages without releasing the old ones.

Potential mitigation: GlazeWM could skip re-managing windows that have visible_on_all_workspaces set, or Tauri/WRY could be investigated for GDI cleanup during window position changes.

[johnsideserf]

Update: narrowed down further

After more testing, the GDI leak has nothing to do with the systray provider (it's not even active in the test widget config). It's purely WebView2 widget windows leaking GDI objects in response to GlazeWM workspace switches.

• Rapidly switching between two workspaces ("terminal" ↔ "code") increases GDI by ~90 objects per batch of switches
• No other apps need to be running — a fresh reboot with just Zebar + GlazeWM reproduces it
• GlazeWM config already has window_rules: [commands: ['ignore'], match: [window_process: {equals: 'zebar'}]] but the leak still occurs
• The earlier Telegram/Discord correlation was a red herring — the user was switching workspaces to reach those apps

This is a WebView2/WRY issue where GDI resources (likely device contexts or bitmaps) are allocated during window composition changes but never freed.

[johnsideserf]

Update: hotkey vs click

Further testing reveals:

• Clicking workspace buttons in the Zebar widget → GDI leaks (~90 per batch of switches)
• Using hotkeys to switch workspaces → no GDI leak

The difference: clicking routes through WebView2 (mouse event → JS handler → IPC call to GlazeWM), while hotkeys are handled directly by GlazeWM without touching WebView2.

This suggests the leak is in WebView2's input/rendering pipeline — specifically when it's actively processing user interaction during a workspace/composition change.

[lars-berger]

is there memory buildup on the JS side (inspectable via Memory tab in webview devtools) ? the glazewm provider is actually a bit different than the other providers in that it's run entirely client-side via a WS connection to the GlazeWM instance

[johnsideserf]

Additional diagnostics (per Lars's suggestion)

Checked JS-side memory and DOM on the GlazeWM provider's client-side WebSocket connection:

• JS heap: ~500KB growth after heavy switching — not significant
• DOM nodes: Stable at 47, no accumulation
• Debouncing re-renders: Reducing 3-4 re-renders per switch to 1 had no effect on GDI leak rate
• Rust-side GDI deltas: Zero across all instrumented code paths

Filed upstream: tauri-apps/wry#1691

Workaround: A GDI watchdog script that auto-restarts Zebar when GDI count exceeds a threshold has been set up locally.

[lars-berger]

i'd be suspicious of simple button clicks causing a leak in wry. it's easily testable by just removing the onclick handler for workspace switches. my guess would be something not being GC'd correctly in zebar's library code (should show in heap profile though), or perhaps something with websockets in wry or webview. does it continue to climb past 500KB or does it stop there?

[johnsideserf]

Root cause identified: WebView2 leaks GDI objects on mouse movement

The GDI leak is not related to workspace switching, clicks, CSS, or any Zebar code. WebView2 leaks GDI objects whenever the mouse moves over its rendering surface.

Hovering over static text (CPU readout, clock) with no interactive elements and no CSS hover styles:

12:26:36 | gdi=42
12:27:06 | gdi=2268  (+2226 in 30 seconds)

For taskbar widgets at screen edges where the mouse constantly crosses, this causes rapid GDI exhaustion. Filed and updated upstream: tauri-apps/wry#1691

Workaround: A GDI watchdog script that auto-restarts Zebar when GDI count exceeds a threshold.

[lars-berger]

are you sure? 👀 again, quite sus that something as simple as mouse movements would leak in either WebView2 or wry. what happens if you just have a plain HTML document with some <p> tags?

[johnsideserf]

Confirmed: pre-existing WebView2 bug, not Zebar-specific

Built and tested clean main branch (no provider changes) — GDI leak is identical. This bug exists in stock Zebar and affects all users, not just the GPU provider branch.

Root cause

WebView2 leaks ~1 GDI object per mouse movement event over its rendering surface. For taskbar widgets at screen edges, this accumulates rapidly (~2000 GDI objects per 30 seconds of mouse activity).

Attempted fixes (all failed)

Approach	Result
Defer NotifyParentWindowPositionChanged in WRY parent subclass	No effect
ICoreWebView2Controller::SetIsVisible(false/true) toggle	Made it worse (~6000/30s)
Subclass WebView2 child windows to throttle WM_MOUSEMOVE	No effect
Thread-level WH_MOUSE hook to intercept WM_MOUSEMOVE	No effect
--disable-gpu-compositing browser arg	No effect
CSS: remove :hover rules and transition	No effect
CSS: pointer-events: none	No effect
JS: debounce React re-renders	No effect
JS: setTimeout delay before workspace switch	Minimal effect
JS: document.activeElement.blur() before switch	No effect
JS: onMouseDown with preventDefault	No effect
Route commands via shellExec CLI instead of WebSocket	No effect

Why nothing works

WebView2 routes mouse input through DirectComposition, bypassing the Win32 message queue entirely. Thread hooks, window subclassing, and message filtering cannot intercept it. The GDI allocation happens deep inside WebView2's closed-source rendering pipeline.

Filed upstream

• Microsoft WebView2: [Problem/Bug]: WebView2 leaks GDI objects on mouse movement over rendering surface MicrosoftEdge/WebView2Feedback#5536
• WRY: WebView2 leaks GDI objects on mouse movement over rendering surface tauri-apps/wry#1691

Workaround

A GDI watchdog script that auto-restarts Zebar when GDI count exceeds a threshold (included in the repo at ~/.glzr/zebar/gdi-watchdog.ps1).

[johnsideserf]

Confirmed with plain HTML — zero JS, zero providers

Replaced the widget with a minimal HTML file:

<!DOCTYPE html>
<html>
<body style="background: #1a1b26; color: white; font-family: sans-serif; padding: 8px;">
  <p>Plain HTML test - no JS, no providers</p>
  <p>Hover over this text and watch GDI count</p>
</body>
</html>

Result — still leaks ~4000 GDI objects in 30 seconds of mouse hovering:

13:14:37 | gdi=30
13:15:07 | gdi=4085

This is a pure WebView2 bug. No JavaScript, no providers, no React, no CSS transitions, no hover styles — just static <p> tags.

[lars-berger]

it doesn't necessarily guarantee a leak if GDI objects are being created. if these are tied to JS objects, then they'd only be cleared on the next GC cycle

[johnsideserf]

it doesn't necessarily guarantee a leak if GDI objects are being created. if these are tied to JS objects, then they'd only be cleared on the next GC cycle

• GDI count never decreases, only increases
• Leaving the widget idle for minutes after hovering — no drop
• Forcing GC via devtools Memory tab garbage collect button — no drop
• Tested with plain HTML (<p> tags only, zero JS) — still leaks
• Restarting Zebar is the only thing that resets the count