On Tue Jun 16 14:49:05 2026 +0000, Marc-Aurel Zent wrote:
In v2 the API is now consumed in `macdrv_vulkan_surface_create`, so it should be less brittle now (and also serves a little bit as documentation for external projects as well). Well as you can see it's been broken by https://gitlab.winehq.org/wine/wine/-/merge_requests/11093, and I'm sorry about it but I think it's more of an indication that it's not a good idea to integrate with Wine internal surface details that way.
It might be more future proof to integrate through Vulkan, for instance with a Vulkan extension to retrieve a Metal layer from a Vulkan swapchain. Ideally that extension would be an official one, but we could perhaps consider keeping it only in Wine if upstreaming such a Vulkan extension is problematic for some reason. Note as well that I don't think we can make any guarantee that every Vulkan swapchain will ever been implemented on top of Metal layers, so any consumer should be ready to handle cases where it's not. I expect this to be the case for instance whenever we will want to implement composited Vulkan swapchains, which will likely use fake swapchain and Vulkan images we control. I don't know how this could then work with third party D3D implementations that don't use Vulkan, I'm not sure it can, but I also don't see any way we can support that with current Wine architecture. Ultimately, and if Metal needs to be a first class citizen we would probably need to have some win32u public interface the same way we have GL and Vulkan, but I don't expect that to be an easy sell. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11058#note_143315