http://bugs.winehq.org/show_bug.cgi?id=60248 Bug ID: 60248 Summary: Roblox Studio 0.736: the editor never appears after opening a place (no document view, no dock widgets) Product: Wine Version: 11.16 Hardware: x86-64 URL: https://create.roblox.com/docs/studio/setup OS: Linux Status: UNCONFIRMED Keywords: regression Severity: normal Priority: P2 Component: winevulkan Assignee: wine-bugs@list.winehq.org Reporter: me@qwreey.moe Target Milestone: --- Regression SHA1: 2293b0e8ca1dc36f0c89a396309997f65e5759fa Distribution: ArchLinux Created attachment 81960 --> http://bugs.winehq.org/attachment.cgi?id=81960 On the parent ec23c07b, identical configuration:the full editor appears, the Baseplate renders in the 3D viewport, and Roblox Studio 0.736.0.7361346 opens and runs, but after opening a place its editor UI never appears. The window title changes to the place name and the ribbon switches to the place-editing one, but the document area keeps showing the Start Page (or is blank if the Start Page was already dismissed), the 3D viewport is not visible, and none of the dock widgets — Explorer, Properties, Toolbox, Terrain Editor — appear at all. The place itself loads fine: the engine logs a normal graphics initialisation, an activated IDE document and correctly-sized render targets, and reports no error. On the parent commit the exact same steps produce the full editor, with the 3D viewport rendering and every dock widget in place. See the two attached screenshots. Bisected to: 2293b0e8ca1dc36f0c89a396309997f65e5759fa "win32u: Keep unused client surfaces around and reuse them if possible." Its parent ec23c07b4514adb5e953dcd230ac061a0c6b5bf5 is good. 2293b0e8's own commit message describes it as addressing applications recreating their VkSurfaceKHR after VK_SUBOPTIMAL_KHR, which is what bug 59640 ("Roblox Studio's 3D-viewport turns blank or flickers (VK_SUBOPTIMAL_KHR)") is about. So this may be a fix for that bug which made the same application's viewport blank permanently instead of intermittently. STEPS TO REPRODUCE ------------------ Roblox Studio is normally launched on Linux through Vinegar (https://vinegarhq.org), which manages the Wine prefix and downloads Studio. Studio itself is x86_64-only. No DLL overrides or Windows DLLs are needed to see this — use Studio's own native Vulkan renderer: 1. Install Vinegar, log in, let it install Roblox Studio. 2. In ~/.config/vinegar/config.toml: [studio] renderer = "Vulkan" # Studio's native Vulkan renderer; with this, webview = "" # Vinegar installs no DXVK and sets no d3d11/dxgi # override at all wineroot = "/path/to/wine" # the Wine build under test 3. Launch Studio and open any place (e.g. the "Baseplate" template). 4. The place opens, but no editor appears: no 3D viewport, no dock widgets, and the document area still shows the Start Page. No error is shown and none is logged. I verified this exact configuration on the bad commit: Roblox reports "[FLog::CreateGraphicsEngine] Using graphics mode 6-Vulkan", WINEDLLOVERRIDES contains no d3d11/dxgi/d3d9 entry, and no DXVK DLL is present in the application directory or loaded into the process. The viewport is still blank. So this does not depend on DXVK or on any DLL override. With the parent commit the 3D scene renders normally. The same Wine prefix works with either build, so switching between them needs no prefix recreation. Disclosure about the prefix: it is created by Vinegar rather than being a stock ~/.wine. The only DLL overrides Vinegar sets in the configuration above are disabling dxdiagn, winemenubuilder, mscoree and mshtml. It does not override d3d11/dxgi/d3d9 unless a DXVK renderer is selected. HOW IT WAS BISECTED ------------------- Built upstream Wine (unpatched, straight from git) twice, 64-bit only, from the same source tree and the same build directory, changing only the checked-out commit: A wine-11.15-29-gec23c07b451 (parent) -> viewport renders correctly B wine-11.15-30-g2293b0e8ca1 (this one) -> viewport renders nothing ../wine/configure --enable-archs=x86_64 --prefix=/opt/wine-test \ --disable-tests --without-oss make && make install Everything else was held fixed across the two runs: same container, same Mesa (26.2.1), same Roblox Studio build (0.736.0.7361346), same Wine prefix, same GPU. Only the Wine install being used was repointed between the two. Build B was then re-tested in the DXVK-free configuration described above (native Vulkan renderer, no d3d11/dxgi override, DXVK DLLs removed from the application directory) and reproduces identically. WHAT THE SYMPTOM ACTUALLY IS ---------------------------- This is not "the viewport window was never created", and it is not a window placement or stacking problem. Running with DXVK's HUD enabled (DXVK_HUD=devinfo,fps) makes the distinction visible: two HUDs are drawn, one on the ribbon's swapchain and one at the top-left of the document area, and the second one updates at 60+ fps over an otherwise empty area. So a swapchain covering the document area is created, presented at full framerate, in the right place, with DXVK's overlay drawing into it — what is missing is the application's own content. (That observation uses DXVK, but the bug itself does not need it — see the repro steps above, which use Studio's native Vulkan renderer and no overrides.) I mention this because a screenshot of the bug is indistinguishable from "no viewport at all", which is what made it hard to characterise. SCOPE ----- Reproduces regardless of: Roblox Studio build 0.734.0 / 0.735.0 / 0.736.0 Renderer Studio's native Vulkan renderer, and DXVK 2.7.1 Display driver winex11.drv and winewayland.drv Wine virtual desktop on and off Output resolution 576x888 through 1920x1080 Mesa 26.1.6 and 26.2.1 GPU AMD Radeon 780M (RADV PHOENIX) AMD Radeon Graphics / Raphael (RADV RAPHAEL_MENDOCINO) Both renderers and both display drivers failing is what pointed at win32u's shared client-surface path rather than anything driver- or translation-layer-specific. THE CHANGE ITSELF ----------------- The part of 2293b0e8 touching the Vulkan surface path, for reference: dlls/win32u/vulkan.c, win32u_vkCreateWin32SurfaceKHR(): - surface->client = user_driver->pCreateClientSurface( surface->hwnd, 0 ); + surface->client = get_unused_client_surface( surface->hwnd, 0 ); - add_window_client_surface( surface->hwnd, surface->client ); + use_window_client_surface( surface->client, !res ); dlls/win32u/vulkan.c, win32u_vkDestroySurfaceKHR(): + use_window_client_surface( surface->client, FALSE ); i.e. a VkSurfaceKHR now adopts a cached, previously-used client surface instead of always creating a fresh one. Studio's viewport lives in a child window and recreates its surface during startup, so it is presumably getting a reused client surface that is not in the state it expects. I have not worked out the mechanism beyond that. Happy to test patches or gather any further logs. POSSIBLY RELATED ---------------- bug 59640 — Roblox Studio's 3D-viewport turns blank or flickers (VK_SUBOPTIMAL_KHR). Same application, same part of the UI, and 2293b0e8's commit message describes exactly that problem. bug 60173 — winex11.drv: layered window is painted black when a Direct3D/OpenGL swap chain targets it. Filed 2026-08-14, same release window. bug 45277 — Multiple applications need Vulkan child window rendering. bug 59071 — Roblox Studio flickering when resizing docked child windows on winex11 and winevulkan driver. -- 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.