[Bug 60509] New: DwmEnableBlurBehindWindow is a stub: OpenGL windows with an alpha channel (Qt, GLFW transparent framebuffer) are drawn with an opaque black background

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60509

            Bug ID: 60509
           Summary: DwmEnableBlurBehindWindow is a stub: OpenGL windows
                    with an alpha channel (Qt, GLFW transparent
                    framebuffer) are drawn with an opaque black background
           Product: Wine
           Version: 11.0
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dwmapi
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

On Windows, a window rendered with OpenGL can have a per-pixel transparent
background: the application creates a pixel format with an alpha channel and
calls DwmEnableBlurBehindWindow() on the window, and DWM then composites the
window using the alpha channel of the back buffer. Pixels with alpha 0 show the
desktop behind the window.

Two common toolkits do this:

- Qt 5 and Qt 6: for an OpenGL (or Vulkan) QWindow whose format has an alpha
channel (for example a translucent QQuickWindow or a QOpenGLWidget with
Qt::WA_TranslucentBackground), updateGLWindowSettings() in
src/plugins/platforms/windows/qwindowswindow.cpp calls applyBlurBehindWindow():

    blurBehind.dwFlags = DWM_BB_ENABLE | DWM_BB_BLURREGION;
    blurBehind.fEnable = TRUE;
    blurBehind.hRgnBlur = CreateRectRgn(0, 0, -1, -1);
    DwmEnableBlurBehindWindow(hwnd, &blurBehind);

- GLFW 3.3/3.4 with the GLFW_TRANSPARENT_FRAMEBUFFER window hint:
updateFramebufferTransparency() in src/win32_window.c makes the same call with
the same empty region.

In Wine, DwmEnableBlurBehindWindow() is a stub that returns E_NOTIMPL:

  fixme:dwmapi:DwmEnableBlurBehindWindow 0x... 0x...

The alpha channel of the OpenGL back buffer is ignored and the window is shown
with an opaque background: every pixel that should be transparent is drawn
black. Desktop overlays, mascots, widgets and HUD-style applications built with
these toolkits are affected.

Steps to reproduce (GLFW):
1. Build a GLFW program that sets glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER,
GLFW_TRUE) and glfwWindowHint(GLFW_DECORATED, GLFW_FALSE), creates a window and
clears it every frame with glClearColor(0, 0, 0, 0) before drawing a small
opaque shape.
2. Run it in Wine.

Expected: only the shape is visible; the desktop is visible around it, as on
Windows 10/11.
Actual: the shape is drawn on an opaque black rectangle.

I observed this with a Qt 5 / Qt 6 desktop-overlay application (OpenGL windows
with an 8-bit alpha buffer, transparent clear color). I did not run the GLFW
program above; it is given as the smallest reproducer because GLFW goes through
the same DwmEnableBlurBehindWindow() call.

System:
- Wine 11.0 (also 10.0), 64-bit prefix
- Ubuntu 26.04.1 LTS, GNOME Shell 50.1, Wayland session (XWayland,
winex11.drv); a compositing window manager is running, so 32-bit ARGB X11
visuals are available
- NVIDIA GeForce RTX 5070 Ti, driver 615.71.09; same result on an AMD Radeon
780M with Mesa

Notes:
- With the NVIDIA driver, a GLX context created for a 24-bit visual cannot be
made current on a 32-bit ARGB drawable (BadMatch), so supporting this needs
more than switching the visual of the existing window.
- Such windows are often also click-through overlays (WS_EX_LAYERED |
WS_EX_TRANSPARENT): clicks on fully transparent pixels must go to the windows
below, clicks on opaque pixels must still reach the application.
- Bug 52254 is the same kind of problem for DwmExtendFrameIntoClientArea() with
Direct3D 9; this report is about DwmEnableBlurBehindWindow() with OpenGL.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.