Guard repeated WndProc setup and ImGui dispatch - #144
Open
kfhammond wants to merge 1 commit into
Open
Conversation
Bridge window setup can be called again for the same HWND while RemixWndProc is already installed. Treat that path as idempotent instead of unhooking and rehooking the same window procedure, while still refreshing the DirectInput forwarding target. The overlay window can also receive forwarded mouse and keyboard messages after the ImGui Win32 backend has been torn down or before it is fully initialized. Guard all direct ImGui Win32 dispatches behind the active ImGui context and backend platform data so stale window messages are ignored instead of reaching backend state that is no longer valid. This avoids WndProc instability during overlay/menu handoff and shutdown paths without changing normal message handling when the backend is live.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix two WndProc stability paths around Remix window hooking and overlay ImGui message forwarding.
Motivation
The bridge window setup path can be called again for the same
HWNDwhileRemixWndProcis already installed. Before this PR, that same-window case fell through to the implicitunset()/ rehook path, disturbing the active WndProc chain even though the hooked window had not changed.The overlay window can also receive forwarded mouse or keyboard messages while the ImGui Win32 backend is not in a valid dispatch state, such as during overlay/menu focus handoff or shutdown. Those messages were forwarded directly to
ImGui_ImplWin32_WndProcHandler, which assumes the ImGui context and backend platform data are live.What Changed
Two changes:
bridge/src/client/window.cppIf
set(HWND)is called for the same window andRemixWndProcis already installed, treat the call as idempotent. The DirectInput forwarding target is refreshed, but the existing WndProc hook is left in place.src/dxvk/rtx_render/rtx_overlay_window.cppRoute all overlay ImGui Win32 dispatches through a small guard that requires both an active ImGui context and Win32 backend platform data before calling
ImGui_ImplWin32_WndProcHandler.This keeps normal input handling unchanged while the backend is live, but ignores stale forwarded messages when the backend is not ready to receive them.
Net diff:
bridge/src/client/window.cppsrc/dxvk/rtx_render/rtx_overlay_window.cppsrc/dxvk/imgui/dxvk_imgui_about.cpp+37 / -10Testing
git diff --check upstream/main..HEADNVIDIAGameWorks/main.Build note: this change was previously built/tested locally before rebasing onto latest upstream
main. After rebasing, an incremental_Comp64Releaserebuild stops during Meson dependency regeneration because upstream now requiresrtx-remix-ngx_sdk_dlfgversion 4, which is not present in my local packman cache and requiresNVM_GTLAPI_TOKENto fetch. The rebuild does not reach C++ compilation.