Comments (28)
I'm using SDL version 2.0.22 prebuilt, opengl3, windows 11, mingw-64 gcc version 12.1.0 (Rev2, Built by MSYS2 project), and last pulled the imgui docking branch from Nov. 4, 2022. I've been using both my engine code, as well as the example_sdl_opengl3 main file, which appear to behave identically. I'm not sure if this is actually the same bug as previously, especially since it only happens when docking is enabled.
In my testing with this bug, I've found it only occurs when ImGuiConfigFlags_DockingEnable is set. I can only get the window to glitch if I am dragging by the title bar, which enables it to be a dock source. Additionally, when I comment out the "BeginDockableDragDropSource" function call in the "Begin" function, that also stops the bug, but disables docking. This does not happen when I comment out the function "BeginDockableDragDropTarget" a little later in the "Begin" function, both around line 7350.
Lastly when the mouse is dragging the window but the window is not following it (when the bug is active), the window local position does not change, but the global ones do, using the functions 'SDL_GetMouseState' and 'SDL_GetGlobalMouseState' respectively. Viewport local coordinates stay at their last values before mouse left the viewport. Anyone have any thoughts for where to look in the code? I'm running out of ideas.
from imgui.
Short version of what I'm seeing now is that dragging docked windows out of the "main window" does not exhibit the behavior.
However, if I grab an undocked windows (with its own viewport) it does exhibit the behavior. Same if I grab a docked window out of a non-main viewport: the issue manifests. For example, with the demo window (which does not begin docked) I always exhibit the behavior, in my app.
Those repro steps are being very consistent for me in my app. Haven't been able to reproduce in example app yet, though. I'm using the stock imgui SDL and directx backends without any (intentional) trickery, but I am setting some non-default flags and window classes, so it may be influenced by one of those. I'll try to narrow it down or find the right steps to repro in example app.
from imgui.
Here: docking...rokups:rk/fix-5012
Fix is a little bit more involved. That jumpy window when dragged issue i mentioned... I had to use a global mouse coordinates in SDL_MOUSEMOTION
to fix jumpyness. And only with that change i can no longer reproduce current issue.
from imgui.
Ignore the below - I'm seeing it repro even on 0647ba3, it just seems... more difficult to repro? Might be entirely subjective.
Testing my project (requires docking branch), the issue appears to have begun sometime between these two merges from master
:
8567a4cc <-- broken
0647ba3 <-- correct
Looks like the "meat" of the input queue and mouse events landed in the docking branch from that commit range, so that's probably not terribly surprising. :)
from imgui.
I could not repro. I am on a source distrib of SDL ~2.0.17 for Windows.
Which SDL version are you on?
Might be worth updating if you are on a old version, just in case.
Otherwise I guess we would need to find what's interfering for you :/
To investigate further:
- Open
Demo>Inputs>Mouse State
and try to find out what's wrong from dear imgui's point of view: it is the mouse position that is clamped? mouse buttons that are released? - In Metrics->Internal State how does the
MouseViewport
values behave when that happen?
from imgui.
I'm using the prebuilt 2.0.16 package from libsdl.org. I'll try an upgrade and get the extra diag info posted here soon(-ish).
from imgui.
I have the same problem. Also resizing on top of another viewport causes twitching
.
from imgui.
@JustQu Does it also happens for you on the stock unmodified example?
from imgui.
@ocornut yes, just builded sdl_opengl3 example and still the behavior is the same.
from imgui.
Does 1.86 give you same result ?
from imgui.
1.86 works fine, window moving and resizing
from imgui.
(see comment below: maybe not actually fixed by upgrading after all)
I verified that updating to SDL 2.0.20 (using the prebuilt VC downloads at http://libsdl.org/download-2.0.php) resolves the issue for me, both in my app and in the imgui example binaries.
Happy to just call this an SDL bug and close this issue on my end (assuming @JustQu's issue is also resolved by updating).
from imgui.
Thanks, that's good to know.
This is not ideal/great I'll still probably want to investigate a little bit with SDL 2.0.16 if we can find a workaround to minimize the issue, and at minimum we'll add commentas about it.
from imgui.
Yeah, also, maybe hold up on that confirmation. I can't get it to repro in the example app, and the repro steps in my app are different but I can still get it to happen. Trying to figure out exactly what the repro steps are, then seeing if I can reproduce in the example app. Either way I'll try to get that diagnostic information you asked for.
from imgui.
There are various factors involved:
The SDL backend now enable io.BackendFlags |= ImGuiBackendFlags_HasMouseHoveredViewport
As I displayed the value of io.MouseHoveredViewport
:
ImGui::Text("MouseHoveredViewport: 0x%08X", io.MouseHoveredViewport);`)
it became clear that SDL Backend reports a "flickering" value when moving near the edge of a window. I am pretty sure that commenting the line setting ImGuiBackendFlags_HasMouseHoveredViewport
in the backend would essentially "fix" the issue by reverting to the old behavior of letting dear imgui guess the hovered viewport based on its knowledge of where viewports area. So we can probably revert to it.
When dragging a viewport it is temporarily set to _NoInputs for the purpose of retrieving the window "under" (for e.g. docking).
Since the SDL backend doesn't honor this flag, when that viewport is reported Dear ImGui automaticaly also reverts to guessing the hovered viewport.
Almost certainly, on the setup where this is broken, if you click and drag from near the edge of a viewport you are more likely to hit the bug as on a given moving frame you will more often stray outside the last viewport boundaries).
from imgui.
@rokups seems to repro it too:
so far i could only notice extra AddMouseViewportEvent(0) event in cases where window fails to continue moving after detachment on a rapid mouse flick. it seems like mouse cursor may end up outside of viewport window for a brief moment and that stops drag operation.
I can't get AddMouseViewportEvent(0)
here.
Logs would be useful to tell if that zero comes from a _LEAVE event or else.
In addition I don't understand what "stops" the dragging because once moving the MouseViewport gets locked to MovingWindow->Viewport. Can you put a break-point on the three occurrences of g.MovingWindow = NULL
(other than constructor) to tell. Most likely it happens in UpdateMouseMovingWindowNewFrame()
, it is because MouseDown[0] == false or because io.MousePos
is invalid?
Here are a few debug lines to add in imgui_impl_sdl.cpp:
#include "imgui_internal.h"
if (window_event == SDL_WINDOWEVENT_ENTER)
{
if (io.KeyCtrl)
{
ImGuiViewportP* viewport = (ImGuiViewportP*)ImGui::FindViewportByPlatformHandle((void*)SDL_GetWindowFromID(event->window.windowID));
IMGUI_DEBUG_LOG("SDL_WINDOWEVENT_ENTER windowID=0x%08X viewport=0x%08X (%s)\n",
event->window.windowID, viewport ? viewport->ID : 0, viewport && viewport->Window ? viewport->Window->Name : "");
}
bd->MouseWindowID = event->window.windowID;
}
if (window_event == SDL_WINDOWEVENT_LEAVE)
{
if (io.KeyCtrl)
{
ImGuiViewportP* viewport = (ImGuiViewportP*)ImGui::FindViewportByPlatformHandle((void*)SDL_GetWindowFromID(event->window.windowID));
IMGUI_DEBUG_LOG("SDL_WINDOWEVENT_LEAVE windowID=0x%08X viewport=0x%08X (%s)\n",
event->window.windowID, viewport ? viewport->ID : 0, viewport && viewport->Window ? viewport->Window->Name : "");
}
bd->MouseWindowID = 0;
io.AddMousePosEvent(-FLT_MAX, -FLT_MAX);
}
if (io.KeyCtrl)
{
IMGUI_DEBUG_LOG("AddMouseViewportEvent viewport=0x%08X\n", mouse_viewport_id);
}
io.AddMouseViewportEvent(mouse_viewport_id);
from imgui.
I think this may be the same as GLFW #4984 and same workaround 732bc20 could work.
I guess you are getting a SDL_WINDOWEVENT>SDL_WINDOWEVENT_LEAVE event without a SDL_MOUSEMOTION leaving MousePos invalid for one-frame which drops the moving.
If you can confirm that I think we can come up with a workaround.
from imgui.
732bc20 does indeed fix this issue 👍🏻
from imgui.
from imgui.
Verified that @rokups fix-5012 branch resolves all the cases I can think of to test locally. Dragging undocked windows, docking/undocking, dragging windows after undocking, etc. all are behaving correctly for me now.
from imgui.
Also saw that he has a newer rk/fix-5012-again -- tested that, it also solves this locally for me.
from imgui.
@seanmiddleditch
Does it works for you with this?
75d9296
This should be a rewording on Rokas's top-most commit (same logic but more explicit)
(Without the earlier commits which are related to another issue seemingly pertaining to X11)
from imgui.
@ocornut - it does indeed
from imgui.
Merged f337378
Thanks everyone for your help!
The other (unrelated) fix for stuttering cursor on SDL+X11 will be pushed separately.
from imgui.
Note how #5082 revealed another issue.
Pushed 9b0c26b to fix in docking, also pushed c5f6721 in master which is == f337378 + 9b0c26b
from imgui.
Hello, does this bug still happens for you with the latest SDL2 version? I can't reproduce it on my end with SDL 2.0.22.
I pushed a fix some months ago about a related issue (libsdl-org/SDL#4832), and many more mouse related fixes were added to the SDL since then. I'd like to know if the SDL_CaptureMouse function is finally working as intended or if it still need to be fixed.
from imgui.
This has been broken in a recent imgui docking commit again. After updating from 64b88da the bug happens again. I am using opengl2 SDL (2.0.22) as the backend. I suspect 51bbc70 broke this once again, but I can't confirm at the moment.
from imgui.
Thank you both. I can confirm the issue and can confirm that 51bbc70 (#5710) broke it when we changed:
SDL_CaptureMouse(bd->MouseButtonsDown != 0 ? SDL_TRUE : SDL_FALSE);
to
SDL_CaptureMouse((bd->MouseButtonsDown != 0 && ImGui::GetDragDropPayload() == nullptr) ? SDL_TRUE : SDL_FALSE);
Removing this unfortunately means that we cannot rely on io.AddMouseViewportEvent()
calls while drag and dropping as SDL doesn't gives us the correct information when capturing.
Instead of completely disabling ImGuiBackendFlags_HasMouseHoveredViewport
in SDL backend I am trying a more dynamic approach with fix d7aca16
from imgui.
Related Issues (20)
- How I can do something when a widget changed its data HOT 1
- Inconsistent result between AddImageRounded and AddImage
- how to zoom a picture hard edges HOT 2
- Docking DockBuilder with DockSpaceOverViewport
- Rendering result on ImGui::Image is wrong during resizing ImGuiViewport HOT 1
- Custom ini setting handler saves settings but does not load settings HOT 2
- How to handle key events properly. HOT 7
- "Hold SHIFT to enable Docking window" tooltip inherits `NextWindowData` HOT 1
- SDL3 backend text input does not work HOT 2
- How to create a very big table? HOT 1
- Standalone ImDrawList/ImDrawCmd/Low level renderer API HOT 2
- `TextWrapped` will cause `too-many-vertices` error for long single-line strings HOT 2
- How do I load custom fonts in memory? HOT 2
- PDIRECT3D11 HOT 1
- Is it possible to create non-square buttons? HOT 4
- Image canvas implementation HOT 15
- Unable to use Menu HOT 3
- Gallery: Post your screenshots / code here (PART 19) HOT 39
- Drag and Drop from Menubar HOT 5
- What's the proper way to render custom text or custom items in the "key"/"label" of a TreeNode? HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imgui.