protonscr

Zoom Player

protonopen appid 269550Game compatibility - Unofficial
ValveSoftware/Proton#10219 · opened 2026-10-04 by bLightZP · updated 2026-10-05 · 1 comments · github · game page · search this game
BbLightZP 2026-10-04 github

Compatibility Report

  • Application: Zoom Player, modern control overlay.
  • Steam AppID: 492590. The actual application tested was standalone Zoom Player MAX Debug 23.00 Beta 3 build 6, launched outside Steam, not the Steam edition.
  • Scope: a layered child window drawn with UpdateLayeredWindow is 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)

  • Ubuntu 24.04.5 LTS, x86_64, kernel 7.0.0-38-generic.
  • GNOME X11 session, 1280x800.
  • VirtualBox 7.1.6r167084: VMSVGA, 128 MB VRAM, 3D acceleration disabled; 2 vCPUs, 4 GB guest RAM.
  • Renderer: llvmpipe (LLVM 20.1.2, 128 bits), Mesa 25.2.8-0ubuntu0.24.04.4; no accelerated GPU exposed to the guest.
  • Host: Windows 10, Intel Core i7-2600K. VirtualBox uses its Hyper-V/NEM backend.
  • Launcher: umu-launcher 1.4.4-1, GAMEID=umu-default, STORE=none.
  • UMU-Proton-10.0-4 / Steam Linux Runtime sniper 3.0.20260928.262393.
  • GE-Proton11-7 / steamrt4 4.0.20260928.262390, tested in a separate copied prefix.
  • No Steam-client system-information report was collected; these were non-Steam launches.

Checks

  • [x] Searched this tracker for Zoom Player and UpdateLayeredWindow; no existing Zoom Player compatibility report found.
  • [ ] System-update check and confirmation on the current official Valve Proton build remain outstanding.

Symptoms

The modern overlay is a WS_CHILD | WS_EX_LAYERED window owned by the player's main window. Its Win32 parent, style and GetWindowRect bounds are correct, and UpdateLayeredWindow returns 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

  1. Launch the standalone build above with either tested runner.
  2. Select the modern UI and place the window away from the desktop origin.
  3. Reveal the modern control overlay.
  4. Observe the overlay detached from its parent, towards the desktop's upper-left.

Independent C++ Win32 test

The attached LayeredChildProbe-cpp.zip contains 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.

  1. Extract the ZIP and run LayeredChildProbe.exe with your Wine/Proton runner, or rebuild it with MinGW using the commands below.
  2. Observe the red/blue child surfaces above the white host window, even overlapping the console, despite their logical rectangles being inside that host.
  3. The test exits automatically after 15 seconds. It prints API results to the console and writes LayeredChildProbe-output.txt when 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:

sudo apt install g++-mingw-w64-i686-posix
i686-w64-mingw32-windres LayeredChildProbe.rc -O coff -o LayeredChildProbe.res.o
i686-w64-mingw32-g++ -std=c++11 -Wall -Wextra -Werror -O2 -static -s LayeredChildProbe.cpp LayeredChildProbe.res.o -o LayeredChildProbe.exe -lgdi32 -luser32

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):

WINEPREFIX=/path/to/test-prefix \
PROTONPATH=/path/to/GE-Proton11-7-x86_64 \
GAMEID=umu-default STORE=none PROTON_LOG=1 \
umu-run explorer.exe /desktop=CppOverlayProbe,1280x800 'Z:\path\to\LayeredChildProbe.exe'

Expected versus observed

For mode 0, pptDst=NULL should 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:

Mode Destination supplied to ULW GetWindowRect after call (L,T,R,B) Observed surface origin
0, red NULL 274,283,424,383 20,60 — wrong
1, green Explicit screen point (454,283) 708,506,858,606 454,283 — pixels move, logical bounds become wrong
2, blue Explicit parent point (380,60), diagnostic experiment 634,283,784,383 380,60 — wrong
3, red Screen point (814,283), then SetWindowPos back to original parent point 814,283,964,383 560,60 — wrong again

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

  • Independent C++ reproducer, manifest/resource, README, prebuilt executable and recorded output (ZIP).
  • GE-Proton11-7 log from the C++ probe, collected with PROTON_LOG=1.
  • Screenshot of the C++ probe's displaced colored child surfaces.
  • Screenshot of Zoom Player's detached modern controls on GE-Proton11-7.

Zoom Player: modern controls detached from the player

Zoom Player modern overlay displaced towards the desktop origin

C++ reproducer and diagnostic evidence

LayeredChildProbe-cpp.zip

cpp-probe-ge11-proton.log

C++ Win32 probe: red and blue layered child surfaces drawn outside the host

BbLightZP 2026-10-05 github

Physical-hardware follow-up — 2026-10-05

The Zoom Player application symptoms now reproduce on physical Linux hardware, outside VirtualBox, using a fresh prefix with no VM settings imported.

Environment

  • Standalone Zoom Player MAX Debug 23.00 Beta 3 build 6, launched outside Steam.
  • Ubuntu 24.04.5 LTS, x86_64, kernel 7.0.0-31-generic.
  • GNOME X11, 1920×1080, 96 DPI.
  • Intel HD Graphics 4000 (Ivy Bridge); glxinfo reports accelerated rendering with Mesa 25.2.8-0ubuntu0.24.04.4.
  • umu-launcher 1.4.4-1, GAMEID=umu-default, STORE=none.
  • UMU-Proton-10.0-4 / Steam Linux Runtime sniper 3.0.20260928.262393.
  • MP3 loaded; no video renderer needed to reproduce the overlay symptom.

Overlay positioning and transparency

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.

Physical Linux, ordinary GNOME desktop: misplaced modern overlay with visible translucency

With a 1920×1080 Wine virtual desktop: the overlay remains displaced, and the modern title/control overlay backgrounds become opaque black rectangles.

Physical Linux, Wine virtual desktop: displaced modern overlays with opaque black backgrounds

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.

Separate fullscreen observation

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.

Remaining test boundaries

  • The independent C++ layered-window reproducer was not rerun on physical hardware; its previously reported VM results are unchanged.
  • Unmodified Valve Proton, stock Wine, and Wayland remain untested.
  • No Zoom Player production source changes were made for this physical-hardware UI review.

Proton versions

Launch options