The Zoom Player application symptoms now reproduce on physical Linux hardware, outside VirtualBox, using a fresh prefix with no VM settings imported.
7.0.0-31-generic.glxinfo reports accelerated rendering with Mesa 25.2.8-0ubuntu0.24.04.4.GAMEID=umu-default, STORE=none.3.0.20260928.262393.Without Wine virtual desktop: the modern overlay remains displaced toward the desktop origin. The main X11 window was at (653,277), size 970×550. Zoom Player's own debug log reported intended overlay screen bounds (658,282)-(1618,822), while the overlay was visibly anchored near (5,5). The misplaced controls were still translucent: desktop/player pixels were visible through their background.
With a 1920×1080 Wine virtual desktop: the overlay remains displaced, and the modern title/control overlay backgrounds become opaque black rectangles.
These application symptoms are therefore not specific to VirtualBox or its graphics emulation. The transparency difference is an observed A/B result on this setup; its underlying cause has not been isolated.
Without Wine virtual desktop, fullscreen failed in both modern and Classic UI: Zoom Player logged fnfullscreen -> fnzoom, but the X11 window stayed 970×550 while the internal content enlarged and became clipped. This was observed with Alt+Enter and the Classic title-bar fullscreen button.
Launching inside a monitor-sized Wine virtual desktop fixed the window transition: the player reached 1920×1080 at (0,0) and restored to 974×642 at (480,208). Multiple enter/restore cycles passed. Classic UI avoids the broken modern overlay.
The tested virtual-desktop launch shape, using the environment above and the same prefix, was:
umu-run explorer.exe /desktop=ZoomPlayer,1920x1080 'C:\Program Files (x86)\Zoom Player Debug\zplayer.exe' 'C:\test.mp3'
An application configuration detail: selecting the Classic preset enables hot corners. Setting Advanced Options → Interface → Mouse → Settings → Hot Corner size to 0 prevents its bottom-right hot corner from intercepting the Classic control-bar fullscreen button and opening Media Library. The button then restored the window successfully.
The fullscreen symptom has not been established to share the overlay bug's underlying cause.
proton 10.0-4x2 2026-10ge-proton11-7x1 2026-10PROTON_LOG=1x1 2026-10WINEPREFIX=/path/to/test-prefixx1 2026-10
Compatibility Report
UpdateLayeredWindowis displayed at the wrong desktop coordinates. An independent Win32 reproducer is attached.Testing status (updated 2026-10-05): originally reproduced with UMU-Proton-10.0-4 and GE-Proton11-7-x86_64, via umu-launcher, in a Linux VM. The Zoom Player application overlay symptoms are now also confirmed on physical Ubuntu/GNOME X11 hardware with Intel HD Graphics 4000, using UMU-Proton-10.0-4 and a fresh prefix. See the physical-hardware results and screenshots, including the ordinary-desktop versus Wine-virtual-desktop transparency comparison and a separate fullscreen observation.
Remaining limitations: an unmodified Valve Proton build, stock Wine, and Wayland remain untested. The independent C++ reproducer has not yet been rerun on physical Linux hardware; its original VM results below are unchanged.
System Information (original VM tests)
7.0.0-38-generic.25.2.8-0ubuntu0.24.04.4; no accelerated GPU exposed to the guest.GAMEID=umu-default,STORE=none.3.0.20260928.262393.4.0.20260928.262390, tested in a separate copied prefix.Checks
Symptoms
The modern overlay is a
WS_CHILD | WS_EX_LAYEREDwindow owned by the player's main window. Its Win32 parent, style andGetWindowRectbounds are correct, andUpdateLayeredWindowreturns success, but its pixels appear at parent-relative coordinates interpreted as desktop coordinates.Example from the player: with the main window at (200,140), the overlay's reported screen rectangle is (205,145)-(1165,685), while its pixels appear at (5,5). Moving the main window therefore separates its controls from the player.
The player also shows opaque black regions in the modern overlay when using a Wine virtual desktop. That transparency symptom has not been isolated independently; the diagnostic below isolates positioning.
The application symptom occurs both with and without a Wine virtual desktop, on both tested runners. No video renderer is necessary: it occurs with an MP3 loaded, and the independent test only uses User32/GDI and a 32-bit DIB.
Reproduction
In the application
Independent C++ Win32 test
The attached
LayeredChildProbe-cpp.zipcontains a standalone C++ source file, a minimal manifest/resource script, build instructions, a prebuilt 32-bit Windows executable, and its recorded output. No Delphi, Python runtime, Zoom Player code/resources, codecs, media, or third-party DLL installation is required.LayeredChildProbe.exewith your Wine/Proton runner, or rebuild it with MinGW using the commands below.LayeredChildProbe-output.txtwhen the current directory is writable. Exit code 0 means the API calls succeeded; it does not mean rendering was correct.The supplied C++ executable was built with MinGW GCC 13-posix and verified on GE-Proton11-7. It reproduced the same coordinate discrepancy. Its imports are limited to GDI32, KERNEL32, msvcrt and USER32.
Build on Ubuntu using the distribution's MinGW cross-compiler:
These build commands passed with warnings treated as errors. A Visual Studio x86 build recipe is also included in
README.txt, but has not been tested here.Example launch in an existing test prefix (substitute your local paths):
Expected versus observed
For mode 0,
pptDst=NULLshould preserve the child's current position and draw inside the parent. Microsoft documents that layered child windows are supported from Windows 8 and that a null destination preserves position: UpdateLayeredWindow. The embedded manifest declares Windows 8/8.1/10 compatibility.In the self-contained GE test, the top-level window is at (250,200), with client origin (254,223). Every ULW call returns TRUE:
Modes 1–3 are diagnostic experiments, not proposed workarounds. The first mode alone demonstrates the original problem. The pattern suggests a parent/client-to-screen coordinate mismatch, but the responsible Wine/Proton implementation has not been identified. This exact independent test has not yet been run natively on Windows for an A/B comparison.
The probe uses fully opaque ARGB pixels to avoid conflating alpha blending with positioning.
Attachments
PROTON_LOG=1.Zoom Player: modern controls detached from the player
C++ reproducer and diagnostic evidence
LayeredChildProbe-cpp.zip
cpp-probe-ge11-proton.log