MacOS runtime warnings regarding access of NSView/NSWindow properties from a non-main thread #7393
+46
−3
Conversation
This file contains 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
…operties from a non-main thread This issue presents when rendering from a thread that is other than the window thread, more easily reproduced when disabling vsync This commit aims to populate the relevant data into backend_data, by way of dispatch_async (ocurring on the main thread). Those particular backend data items are protected by an NSlock There may be more elegant ways to do this Main Thread Checker imgui/backends/imgui_impl_osx.mm:608 -[NSView window] must be used from main thread only imgui/backends/imgui_impl_osx.mm:608 -[NSWindow backingScaleFactor] must be used from main thread only imgui/backends/imgui_impl_osx.mm:609 -[NSView bounds] must be used from main thread only
…operties from a non-main thread This issue presents when rendering from a thread that is other than the window thread, more easily reproduced when disabling vsync This commit aims to populate the relevant data into backend_data, by way of dispatch_async (ocurring on the main thread). Those particular backend data items are protected by an NSlock There may be more elegant ways to do this Main Thread Checker imgui/backends/imgui_impl_osx.mm:608 -[NSView window] must be used from main thread only imgui/backends/imgui_impl_osx.mm:608 -[NSWindow backingScaleFactor] must be used from main thread only imgui/backends/imgui_impl_osx.mm:609 -[NSView bounds] must be used from main thread only
|
Also see #6528 |
…anitiser concerns This is a little nasty.. I'm trying to keep all changes localised to imgui_impl_osx.mm Ideally the ImGui_IO_lock would live within ImGuiIO but I didn't want to muddy the waters Perhaps better if this lock primitive is delivered through BackendPlatformUserData, and only used where provided This change requires the client platform to explicitly lock the primitive from outside of ImGui around ImGui::NewFrame specifically, and additionally from anywhere on the client side (external to ImGui) that concurrently hooks into ImGuiIO That requires the client to define an extern lock (and use it appropriately) extern NSlock *ImGui_IO_lock If this lock were native to ImGui we could have ImGui::NewFrame() handle the lock on our behalf, negating the need for client side locking
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Xcode Version 15.3 (15E204a)
Resolve Xcode runtime warnings regarding access of NSView/NSWindow properties from a non-main thread
This issue presents when rendering from a thread that is other than the window thread, more easily reproduced when disabling vsync
This commit aims to populate the relevant data into backend_data, by way of dispatch_async (ocurring on the main thread). Those particular backend data items are protected by an NSlock
There may be more elegant ways to do this
The warnings observed are as follows:
Main Thread Checker