Extracting some of the @hinxx discussion away from #9594.
Late latching may mostly be useful for:
- moving imgui windows rendering in main viewports (position/geometry is part of main scene/meshes)
- moving platform windows for secondary viewports (position held by WM/OS)
I honestly won't have time for this as it tends to be highly platform/driver/application dependent, but if there's something I can advise or help with I would try.
As an aside, the exact opposite for late latching would be to disable hw mouse cursor when moving windows, so that the visible cursors is more in sync with windows. I am interested in ways to support disabling hw mouse cursors.
Activity
8
hinxx3d agoThanks for following up on this @ocornut ! Let me create a branch in my fork with your patch and get back to you on the findings by opening a PR.
It presently doesn't have any effect under Windows
By that do you mean that a) you do not see the initial problem of lagging widow on Windows or b) that the patch does not have an effect/fix on Windows? Not using Windows here so I cant tell..
ocornut3d agoThe patch does not have an effect on Windows. There is a still lag on window but it seems bearable to me.
hinxx3d agoI tested your patch (748ab53) on Linux/X11, GLFW 3.3.10, Intel HD 630, @ 60 Hz.
In the video, the left side is upstream docking without the patch and the right side is with your patch, running scripted xdotool drag of demo window, recorded at 60 fps. Without the patch, the window stutters and jiggles around the cursor. With your patch, the stutter is gone, but the window occasionally jumps to 0,0; you can see it on the right near the end.
https://github.com/user-attachments/assets/3f6b25a2-7fcd-4f1c-8ea2-a7c7d4886388
denggold68-eng2d agoBased on my current research into multi-viewport support in Dear ImGui—for which I implemented a multi-threaded architecture, separating the event and rendering threads—I have evaluated several graphics APIs: DX11, DX12, Vulkan, and OpenGL. My findings indicate that when secondary viewports are implemented as independent OS windows, only DX11 performs relatively smoothly, though even then, some stuttering occurs during window dragging. With the other APIs (DX12, Vulkan, and OpenGL), the performance is significantly worse when MSI Afterburner is running; DX12 is the most severely affected, followed by Vulkan, and then OpenGL. I verified this by testing Unreal Engine 5 (UE5) in DX12 mode, where similar stuttering occurs when MSI Afterburner is active. This suggests the issue is not solely inherent to Dear ImGui; it may stem from graphics drivers or the operating system itself. Consequently, I believe Dear ImGui should not be expected to take on the primary responsibility for fixing these issues. Mitigating such stuttering likely requires an approach similar to the one I’ve explored—moving away from the single-threaded strategy used in the official examples by decoupling the event and rendering threads. I cannot provide a universal solution for this separation, as it is highly dependent on the specific requirements of each project. The creation, destruction, and resizing of independent OS-level viewports—which involve managing resources like DX11/DX12 devices and queues, Vulkan devices and queues, or OpenGL contexts—must be carefully handled at the application layer to prevent conflicts with the rendering thread. Furthermore, each additional independent window introduces a complete "present" operation, which significantly increases the overall workload.
ocornut2d ago@hinxx No need to open PR for this. They are experiments and we are unlikely to settle to a fit-all solution anytime soon, so I'd prefer if this all stay in that same issue.
hinxx2d agoAs seen in https://github.com/ocornut/imgui/issues/9616#issuecomment-6779851532 the dragged window occasionally jumps to 0,0 with patch applied.
Fix:
imgui-f292f6f-latelatch-skip-invalid-mouse-pos.patch [Code generated by Claude reviewed by me]
The fix uses the latest MousePos event that passes IsMousePosValid() instead. The video shows your patch on the left and with the fix on the right.
https://github.com/user-attachments/assets/ee7e986c-de4c-4d1d-a9ee-df7a6f0c1d61
This shows that the stutter is gone for me. What remains is the lag between the cursor and the window title bar.
hinxx2d agoI tried letting the WM do the drag on X11. Once window exits Imgui main window app sends _NET_WM_MOVERESIZE and let OS take over. The window then tracks the pointer quite good, maybe a bit better than with the patch above.
imgui-cf53467-example-glfw-wm-move.patch [Code generated by Claude reviewed by me]
We lose the docking ability when the OS window moves back into the main ImGui window. Merging back into the main window works if auto-merge is suppressed during the move. The WM also swallows the button release; that is why the app waits for the next one to forward it.
https://github.com/user-attachments/assets/2ed8498f-1c19-4694-96bd-cba5dc1c27cd
The video is the stock example_glfw_opengl3 with the attached patch, on unmodified upstream docking (no other patches applied). Notice how the docking is offered when leaving the main window and not when entering it later on..
Here's an untested/unverified experiment for late of MousePos while moving secondary viewports in GLFW.
imgui-748ab53-GLFW (unverified) late latching experiment for GLFW secondary viewports.patch
It presently doesn't have any effect under Windows, presumably due to how the event is handled by GLFW and Win32 (as an extreme: if I replace the position parameter of the
Platform_SetWindowPos()call with {0,0} I do NOT see any effect until releasing mouse.), but it'd be interesting to find out how it perform on @hinxx setups.Personally I think the solution to that specific lag in dragging secondary viewports might be handled better by letting the OS/WM do the drag.