I try to write a safer win32 implement for some "working thread" + "Window GUI thread" applications and games.

ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

MIT License

61.16k stars 10.31k forks source link

I try to write a safer win32 implement for some "working thread" + "Window GUI thread" applications and games. #3569

Closed Demonese closed 3 years ago

Demonese commented 4 years ago

Version/Branch of Dear ImGui:

Version: 1.80 (WIP) (17905) Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_win32_workingthread (this is my fork) Compiler: VS2019 Operating System: Windows 10 20H2

My Issue/Question:

My application using a "working thread" + "Window GUI thread" model so the default imgui_impl_win32 may behave in strange ways. I try to write a safer implement and it works well but still lacks testing. I'm not sure if it has any other bugs.

Screenshots/Video

Standalone, minimal, complete and verifiable example: (see https://github.com/ocornut/imgui/issues/2261)

Demonese commented 4 years ago

Nice, I think it's stable enough.

API set
mouse capture
mouse cursor My GIF recorder can't record mouse cursor, I'm sorry. But the mouse cursor change has no problem.
set mouse position My GIF recorder can't record mouse cursor, I'm sorry. But the mouse position change has no problem.
IME candidate list position

Demonese commented 4 years ago

OHHHH! I'm so happy! Now it works on LuaSTG plus engine (a small 2D bullet hell game engine)! LuaSTG plus using "Window GUI thread" + "working thread" model but imgui_impl_win32 not available (has many bugs). LuaSTGPlus engine offiicial site (not my fork/branch) I will continue to test this implement, thanks to ocornut's dear-imgui!

heroboy commented 4 years ago

I see your code. I find you create d3d context in working thread, rendering in working thread. But the window is created in gui thread. Is it good and safe and have good performance? In my opinions the "working thread" + "gui thread" should be like the remote branch of imgui, but in the same process. The whole 'imgui' is living in the working thread, and send the draw data to the gui thread. And the backend is living in the gui thread, and send the user interactive messages to the working thread.

Demonese commented 4 years ago

I see your code. I find you create d3d context in working thread, rendering in working thread. But the window is created in gui thread. Is it good and safe and have good performance? In my opinions the "working thread" + "gui thread" should be like the remote branch of imgui, but in the same process. The whole 'imgui' is living in the working thread, and send the draw data to the gui thread. And the backend is living in the gui thread, and send the user interactive messages to the working thread.

Win32 "GUI thread" is the thread create window and process window messages. I didn't need to draw imgui in "GUI thread" because we have d3d and imgui didn't support GDI.

Demonese commented 4 years ago

I see your code. I find you create d3d context in working thread, rendering in working thread. But the window is created in gui thread. Is it good and safe and have good performance? In my opinions the "working thread" + "gui thread" should be like the remote branch of imgui, but in the same process. The whole 'imgui' is living in the working thread, and send the draw data to the gui thread. And the backend is living in the gui thread, and send the user interactive messages to the working thread.

It's safe enough, but the performance will not increase. Now we can resize window or drag move window and "GUI thread" will not block "working thread". This is the only one benifitial, I think. (In fact I just want to embed imgui into LuaSTG plus engine.)