Fix GL window bleed-through on Win32 with Intel GPUs

[andrewachen]

Problem

On Win32 with Intel integrated GPUs, OpenGL windows show content from windows behind them bleeding through character/text backgrounds. Affects both native WGL and GtkGLArea rendering paths.

Root cause: Intel's ChoosePixelFormat returns a pixel format with 8 alpha bits even when cAlphaBits=0 is requested. DWM reads undefined alpha from the window surface as transparent (freedesktop.org bug #14165).

Confirmed on Intel(R) Graphics, driver build 32.0.101.8508. Does not affect NVIDIA, AMD, or Adreno (ARM64/GLon12).

Fix

The workaround is Intel+Win32-specific, gated on GL_VENDOR containing "Intel". The bulk of the workaround logic lives in platform/win32/gl_context.py to keep platform-specific hacks out of the shared OpenGL code. The shared backing.py only adds a no-op _fixup_present_alpha() hook that the Win32 code overrides.

Intel+Win32 workarounds:

• Force RGBA visual on GL windows so the GDI surface has a proper alpha channel (client_window.py)
• Force alpha in GtkGLArea readback so the surface gets alpha=255 (glarea_backing.py)
• Force alpha=1 via glColorMask+glClear before each present, with a one-time glReadPixels to prime the Intel driver — Intel's glClear doesn't properly respect glColorMask without a prior readback (gl_context.py:setup_intel_workarounds)

Platform-independent:

• Clear non-alpha FBOs with alpha=1 instead of alpha=0 (backing.py)
• Add _fixup_present_alpha hook in do_present_fbo (backing.py)
• Set app_paintable on GL DrawingArea — matches the Cairo path (drawing_area.py)

Testing

Tested on Win32 x64 with Intel(R) Graphics (driver 32.0.101.8508):

• opengl=force (native WGL path) — no bleedthrough
• opengl=force:glarea (GtkGLArea path) — no bleedthrough
• opengl=off (Cairo) — unaffected, still works

Tested on Win32 ARM64 with Adreno X1-85 (GLon12) — no regression, workaround not activated.

Confirmed WS_EX_LAYERED is NOT set on any decorated GL window after the RGBA visual change.

References

• freedesktop.org #14165 — i965 glClear + glColorMask
• Mozilla #1523030 — glBlitFramebuffer ignores glColorMask
• Xpra #2466 — related GTK3 OpenGL Win32 transparency

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
Sponsored-By: Netflix

[andrewachen]

This feels a little invasive and the Intel machine is not my daily driver, so I won't feel terrible if you decide not to merge this -- it's unfortunate that the Intel integrated GPU needs such things.

[totaam]

Claude "max effort" review confirms some of my concerns:

Freedesktop #14165 is real but different. It's a 2009 Mesa/i965 DRI bug — glClear() with glColorMask() caused assertion failures in intel_clear_tris() on Linux. Fixed by restricting that path to front/back-left buffers only. It confirms Intel has a history of glClear+glColorMask misbehaviour, but it's a Linux Mesa driver fix, not the Windows ICD.

2009 on Linux...

The "readback priming" claim has no documented basis found. No Mesa commits, no bug reports, no vendor documentation describes needing a glReadPixels to prime driver state before glColorMask+glClear works correctly on Windows Intel drivers. It appears to be empirically discovered — someone found it worked and shipped it.

Is this absolutely needed?

The ChoosePixelFormat alpha-bits issue is well-known (the DWM bleed-through mechanism is documented), but the specific glReadPixels-as-primer workaround for Windows Intel isn't.

If it is well known, I would expect workarounds to be more common and easier than readback!

Worth noting in the PR review: the code comment/docstring says the primer is needed because "Intel's glClear doesn't properly respect glColorMask without a prior readback", but no reference is cited for that specific claim on Windows. Given the 2009 Mesa fix, it's plausible there's a related Windows driver bug, but the PR would be stronger with a test case or driver version that demonstrates the primer is actually necessary — otherwise it's expensive insurance for an unverified assumption.

Claude was making good progress, but then:

⎿  You've hit your limit · resets 2am

[totaam]

@andrewachen can you try running 88d8abc with XPRA_OPENGL_ALWAYS_RGBA=1?

Claude said:
So ALWAYS_RGBA=1 paired with the PR's FBO clear changes (alpha=0 → alpha=1) could in principle fix the bleed-through without any per-frame workaround — if Intel's glBlitFramebuffer correctly copies the alpha channel from the RGBA8 FBO to the window framebuffer. That's the unknown. If the blit doesn't propagate alpha (which is
plausible for the same class of Intel driver bug), ALWAYS_RGBA alone still leaves the window framebuffer alpha undefined after the blit, and you're back to needing the glColorMask+glClear trick.

Worth testing: it's a much lighter change than the per-frame workaround, but it may or may not be sufficient depending on whether Intel's blit honours the alpha source.

---

I found an Intel card, but it stopped working after a reboot!

[totaam]

The Intel card is working again, turns out that this GPU is so big that it bent the SATA connectors out of their sockets, which prevented the OS from loading...

Anyway, I can test with Intel now, but I'm not seeing any issues. Which app can I used to reproduce the problem and how?