From a0e0115e65631107368dbd49fb35a1e78690a076 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Henrik=20Rydg=C3=A5rd?= Date: Thu, 22 Oct 2026 22:44:16 +0200 Subject: [PATCH] NativeApp: Say why output requests have their own queue Co-Authored-By: Claude Opus 5.5 (1M context) --- UI/NativeApp.cpp | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/UI/NativeApp.cpp b/UI/NativeApp.cpp index 6a1ce6b215..b6977aa5c8 100644 --- a/UI/NativeApp.cpp +++ b/UI/NativeApp.cpp @@ -191,6 +191,11 @@ std::string config_filename; // that consumes it also sees those writes - with a plain bool it could see the flag first and keep stale bounds. static std::atomic resized{false}; +// Secondary outputs are added, resized and removed through their own queue, not pendingMessages or +// g_pendingClosures. Those run mid-frame, after BeginFrame, but creating or destroying a Vulkan swapchain +// stops the render threads, so this runs before BeginFrame. It also runs in NativeInitGraphics before +// deviceRestored, so a removal queued while the graphics were down lands before swapchains are recreated +// (on a surface that may be gone). And it tracks completion for Native_RemoveOutputAndWait. struct OutputRequest { enum class Type { ADD,