Closed ruby3141 closed 6 months ago
The example program you are targeting is hardly a supported use case. As you yourself mention, games don't rely on WM_PAINT
because that's generally intended for desktop applications (see documentation).
WM_PAINT
generally happens as a consequence of interaction whereas games will render their frames continuously and will flat-out ignore it. For this reason, should_block_messages
is going to get invoked every frame unconditional of incoming messages. The current asynchronous messaging design relies on this assumption to minimize the computations happening in the window procedure.
If you have an alternative design to suggest, that can selectively block messages without introducing too much overhead, feel free to share that through a pull request!
My payload uses
should_block_message()
to prevent propagating keyboard input to game when my overlay should handle one. For my target game there's no problem about that (It seems the target only uses wndproc to get keyboard event).Recently I tried to use imgui-rs hello_world example window as a test rig for my overlay UI, and quickly got into trouble.
Turns out the example program uses
WM_PAINT
message as render logic entry. For that situation, ifshould_block_message()
got set, next frame will be unreachable. (Filter and unsafely send message back onon_wnd_proc()
approach is impossible due to that.)Since current "block them all" thing seems very limiting and dangerous in some cases, I think we need other approach.