http://bugs.winehq.org/show_bug.cgi?id=60263 --- Comment #2 from James <winebugs@protonmail.ch> --- Created attachment 82030 --> http://bugs.winehq.org/attachment.cgi?id=82030 Stock-applicable core of the reference implementation (applies to pristine wine 11.16), regenerated 2026-09-03 — obsoletes attachment 82021 Replacing attachment 82021, which needed a tree already carrying the out-of-tree DXMT support patch and, as noted at the time, did not apply to stock wine as-is. This one does. It is the same implementation with the DXMT-specific layer split off, regenerated from git rather than hand-maintained. What it is: the cross-process child window case in window.c's macdrv_client_surface_acquire_metal_swapchain, where the driver currently prints the FIXME and returns FALSE. A child HWND owned by another process gets no cocoa_window of its own; the child's process renders into a CAContext-backed layer and the owner's WineContentView hosts it through a CALayerHost, keyed by the CAContextID, with the owner repositioning and restacking the hosted layer as the child moves. That is the CAContext/CALayerHost route the driver already has for vulkan.c, reached from the Metal side as well. Measured on wine 11.16, 2026-09-03: - Applies to a pristine 11.16 tree with `patch -p1` at fuzz 0. Also applies on top of the DXMT support patch; the insertion points are placed away from its. - Four files: window.c, cocoa_window.m, macdrv.h, macdrv_cocoa.h. +513/-27. - Compiles on pristine 11.16 with no new warnings against the stock build of the driver, and the FIXME string is gone from the built module. - Runtime testing was through the Metal route only: Steam's client, where CEF's GPU process asks for a swapchain on a child window owned by the browser process. That is the black-window case in the description, and it renders. The vulkan.c path compiles and links but I have not exercised it at runtime. - On its own it changes no behaviour for an application that never asks for a cross-process child swapchain. Two fixes since 82021: a child's own move now repositions its hosted layer (previously only a move of the top-level did, which CEF happens to mask by recreating the swapchain), and the paint-order walk no longer has a fixed capacity. Same disclosure as the description: written with heavy AI assistance and offered as a reference for whoever writes the real thing, not as a submission. The header's licensing note is corrected: the modifications are offered under LGPL-2.1-or-later, the licence of the files they touch. The earlier attachment's header carried an MIT sentence, which cannot apply to a diff of LGPL files. -- 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.