http://bugs.winehq.org/show_bug.cgi?id=55432 --- Comment #9 from Wehrwolfmann <wehrwolfmann@gmail.com> --- (In reply to Stian Low from comment #8)
Please retest with wine-staging which added some support for dcomp some months ago
Retested -- thanks for the pointer, the staging dcomp patches do cover this, and they fix the application case as well. Setup: wine-staging 11.15 and vanilla wine 11.15, both distribution builds of the same version (Arch/CachyOS 11.15-1.1), the staging one unpacked into a separate tree so that the two could be measured back to back on one machine. Fresh 64-bit prefixes, no DXVK, no vkd3d, no Steam, no DLL overrides. Renderer is Mesa 26.1.6 radeonsi on an AMD Radeon 780M; the reported Windows version is the default 10.0 build 19045. 1. The probe from comment #6 / attachment 81789 (dcomp_min.exe) wine-11.15 (vanilla) DCompositionCreateDevice(IDCompositionDevice) 0x80004001 E_NOTIMPL DCompositionCreateDevice2(IDCompositionDevice2) 0x80004001 E_NOTIMPL DCompositionCreateDevice3(IDCompositionDesktopDevice) 0x80004001 E_NOTIMPL wine-11.15 (Staging) DCompositionCreateDevice(IDCompositionDevice) 0x00000000 S_OK DCompositionCreateDevice2(IDCompositionDevice2) 0x80004002 E_NOINTERFACE DCompositionCreateDevice3(IDCompositionDesktopDevice) 0x00000000 S_OK 2. A second probe, walking the exact sequence Chromium's viz process performs at startup (direct_composition_support.cc plus DCLayerTree::Initialize) -- the path that the PlanetSide 2 launcher and every WebView2/CEF based application take once the prefix reports Windows 8.1 or newer. On wine-staging 11.15 the whole sequence now succeeds: D3D11CreateDevice S_OK ID3D11Device::QueryInterface(IDXGIDevice) S_OK DCompositionCreateDevice -> IDCompositionDevice S_OK DCompositionCreateDevice2 -> IDCompositionDesktopDevice S_OK DCompositionCreateDevice2 -> IDCompositionDevice2 E_NOINTERFACE IDCompositionDesktopDevice::QI(IDCompositionDevice2) S_OK CreateWindowEx(WS_EX_NOREDIRECTIONBITMAP) ok IDCompositionDesktopDevice::CreateTargetForHwnd S_OK IDCompositionDevice2::CreateVisual S_OK IDCompositionTarget::SetRoot S_OK IDCompositionDevice2::Commit S_OK with only two fixmes left on that path: fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20. fixme:dcomp:device_Commit iface ... semi-stub! On vanilla 11.15 the same probe stops at the third line, since dlls/dcomp/device.c in master is still three FIXME + E_NOTIMPL stubs and nothing else (47 lines), so nothing below the device can be reached. 3. Application level, same machine, one and the same prefix, only the wine build swapped: Razer Axon 2.9.1.0, whose entire UI is the WebView2 runtime (151.0.4129.78), reporting Windows 10, with no per-application Version override of any kind. vanilla 11.15: window stays blank. The GPU process retries and dies in a loop; nine separate processes each log one fixme:dcomp:DCompositionCreateDevice ... fixme:dcomp:DCompositionCreateDevice3 ... and no content is ever painted. staging 11.15: one DCompositionCreateDevice3 call, no restart loop, and the UI paints completely -- text, images, the banner carousel animating between frames. That last point matters beyond this bug: the standing workaround for WebView2 applications has been a per-application Version=win7/win8 override for msedgewebview2.exe (bug 58921). On wine-staging 11.15 that override is no longer needed -- I removed it and the UI renders at win10. On vanilla 11.15 it is still required. Two things that may be worth folding back into the staging patchset: a) DCompositionCreateDevice2 returns E_NOINTERFACE when IID_IDCompositionDevice2 is requested directly, while it succeeds for IID_IDCompositionDesktopDevice. On Windows both are accepted, and the object handed back for IID_IDCompositionDesktopDevice does implement IDCompositionDevice2, as the QueryInterface line above shows. Chromium is not affected because it asks for the desktop device and then QIs, but an application asking for IDCompositionDevice2 up front will still fail. b) In the Razer Axon run, WebView2 also queries {4ca97a18-cbfd-4b0d-89e1-f7fa86d8d63e} on the device and takes E_NOINTERFACE gracefully; visual_SetContent and device_Commit are semi-stubs. Everything still renders, so these are notes rather than blockers. I am attaching the second probe so the sequence can be reproduced without a game launcher or a WebView2 runtime; build with x86_64-w64-mingw32-g++ dcomp_chromium.cpp -o dcomp_chromium.exe \ -ld3d11 -ldxgi -ldcomp -lole32 -luser32 As for this bug's disposition: the failure it describes is gone in wine-staging but unchanged in mainline -- dlls/dcomp/device.c in master has not moved -- so from a mainline point of view it still reproduces in 11.15. Happy to retest anything specific on either build. -- 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.