Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux/Mac compatibility of multi-viewports #2117

Open
ocornut opened this issue Oct 5, 2018 · 90 comments
Open

Linux/Mac compatibility of multi-viewports #2117

ocornut opened this issue Oct 5, 2018 · 90 comments

Comments

@ocornut
Copy link
Owner

ocornut commented Oct 5, 2018

This is a thread for people to discuss Linux/Mac (and notably custom window managers under Linux) specific issues with the Viewport branch, mentioned in #1542.
I am not a Linux user so I hope users will come to a solution to make the various bindings compatible with window managers.

January 2019: Viewport and Docking branches have been merged to simplify maintainance. Use the 'docking' branch to test multi-viewports.

@ocornut ocornut changed the title Linux compatibility of the multi-viewport branch Linux/Mac compatibility of the multi-viewport branch Oct 5, 2018
@ocornut
Copy link
Owner Author

ocornut commented Oct 5, 2018

The discussions involving @Ylannl @ebachard, @s-ol, @Lecrapouille starts around here:
#1542 (comment)

@s-ol
Copy link

s-ol commented Oct 5, 2018

👍

For now I think we should focus separately on the issues with the GLFW and WM integrations I have been mostly posting about and the more subtle problems e.g. @ebachard has been seeing. I think we should focus on the latter as the GLFW stuff (window jitter) is likely a bit further from the imgui core itself and better fixed on a tangent.

I just gave the SDL demo another try on i3 and I noticed some more details, mostly related to the two ways I can interact with the windows; I can either use my WM shortcut to move and resize the windows (in my case hold the Meta key and left/right drag, lets call this WM-dragging/resizing) or I can let ImGui do it (left-drag an empty spot or titlebar, left drag window corner or edges; app-dragging/resizing).

I found the following:

  • When WM-resizing I can only grow windows - dragging in the shrink-direction doesn't affect the window size at all
  • When I WM-drag a window over the main viewport the drag is aborted and I have to pick the window up again to keep position it. This happens in the moment that the dragged window is contained completely inside the main viewport. When app-dragging the window the windows are not merged until the mouse is released (ideal behavior).

@Lecrapouille
Copy link

@ocornut If you want I can try to investigate concerning the segfaut I caught. I think this is not an issue concerning a particular architecture. I just call valgrind on the example_glfw_opengl3: I got:

==3237== Process terminating with default action of signal 11 (SIGSEGV)
==3237==  Access not within mapped region at address 0x0
==3237==    at 0x10B9A2: ImGui_ImplGlfw_GetWindowPos(ImGuiViewport*) (imgui_impl_glfw.cpp:477)
==3237==    by 0x128F91: ImGui::UpdateViewports() (imgui.cpp:7465)
==3237==    by 0x137431: ImGui::NewFrame() (imgui.cpp:3294)
==3237==    by 0x10B202: main (main.cpp:127)

Then I added some asserts:

static ImVec2 ImGui_ImplGlfw_GetWindowPos(ImGuiViewport* viewport)
{
    assert(NULL != viewport);
    ImGuiViewportDataGlfw* data = (ImGuiViewportDataGlfw*)viewport->PlatformUserData;
    assert(NULL != data);
    assert(NULL != data->Window);
    int x = 0, y = 0;
    glfwGetWindowPos(data->Window, &x, &y);
    return ImVec2((float)x, (float)y);
}

And I got Assertion `NULL != data' failed. I never tried rr but I'll give a try to know if it catches the bug https://rr-project.org/

@ocornut
Copy link
Owner Author

ocornut commented Oct 5, 2018

@Lecrapouille
What is the value of viewport->ID ?

It is calling the handler when viewport->PlatformRequestMove was set, which is set in ImGui_ImplGlfw_WindowPosCallback() when the window is moved which means the platform window was created.

There is maybe a possibility this gets called during the frame after window destruction.
Could you add printf() logging in ImGui_ImplGlfw_CreateWindow, ImGui_ImplGlfw_DestroyWindow printing viewport->ID, viewport->PlatformHandle, viewport->PlatformUserData, etc. with a frame counter?

// and the bottom of ImGui_ImplGlfw_CreateWindow
printf("[%05d] CreateWindowID %08X\n", ImGui::GetFrameCount(), viewport->ID, viewport->PlatformHandle, viewport->PlatformUserData);
// at the top of ImGui_ImplGlfw_DestroyWindow
printf("[%05d] DestroyWindow ID %08X\n", ImGui::GetFrameCount(), viewport->ID, viewport->PlatformHandle, viewport->PlatformUserData);

@Lecrapouille
Copy link

In fact to produce the segfault there is an easier way: move the "hello world" window outside (partially) the main win (else this is not working) then just move up and down your mouse cursor on the blue box of clear color to pop up/down the color panel (which starts shaking), this is enough to produce the crash.

Forget for rr I cannot use it with AMD Ryzen :( So I'm using the printf method :

In static void ImGui::UpdateViewports() inside the loop I added:

printf("ImGuiViewportP* viewport = g.Viewports[%d]; %p    %p\n", n, viewport, viewport->PlatformUserData);

Also I added printf in:

IM_DELETE(viewport);
printf("IM_DELETE(viewport) %p  %p\n", viewport, viewport->PlatformUserData);
n--;

And finally inside static ImVec2 ImGui_ImplGlfw_GetWindowPos(ImGuiViewport* viewport)

For me the NULL pointer comes from this code:

static void ImGui_ImplGlfw_DestroyWindow(ImGuiViewport* viewport) { 
...
printf("Before ImGui_ImplGlfw_DestroyWindow %p  %p\n", viewport, viewport->PlatformUserData);
    viewport->PlatformUserData = viewport->PlatformHandle = NULL;
printf("After ImGui_ImplGlfw_DestroyWindow %p  %p\n", viewport, viewport->PlatformUserData);

With valgrind + printf I see that:

--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11914810    0x11918610
Before ImGui_ImplGlfw_DestroyWindow 0x11914810  0x11918610
After ImGui_ImplGlfw_DestroyWindow 0x11914810  (nil)
ImGui_ImplGlfw_GetWindowPos 0xf635380
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11914810    (nil)
ImGui_ImplGlfw_GetWindowPos 0xf635380
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11914810    (nil)
==27446== Invalid read of size 8
==27446==    at 0x1281D3: ImGui::UpdateViewports() (imgui.cpp:7458)
==27446==    by 0x1177D4: ImGui::NewFrame() (imgui.cpp:3294)
==27446==    by 0x10AB9B: main (main.cpp:127)
==27446==  Address 0x11914838 is 40 bytes inside a block of size 224 free'd
==27446==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==27446==    by 0x10EAD6: FreeWrapper(void*, void*) (imgui.cpp:992)
==27446==    by 0x115684: ImGui::MemFree(void*) (imgui.cpp:2815)
==27446==    by 0x145BB4: void IM_DELETE<ImGuiViewportP>(ImGuiViewportP*) (imgui.h:1428)
==27446==    by 0x1281CE: ImGui::UpdateViewports() (imgui.cpp:7457)
==27446==    by 0x1177D4: ImGui::NewFrame() (imgui.cpp:3294)
==27446==    by 0x10AB9B: main (main.cpp:127)
==27446==  Block was alloc'd at
==27446==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==27446==    by 0x10EAB8: MallocWrapper(unsigned long, void*) (imgui.cpp:991)
==27446==    by 0x11562C: ImGui::MemAlloc(unsigned long) (imgui.cpp:2807)
==27446==    by 0x128720: ImGui::AddUpdateViewport(ImGuiWindow*, unsigned int, ImVec2 const&, ImVec2 const&, int) (imgui.cpp:7574)
==27446==    by 0x11F4BB: ImGui::Begin(char const*, bool*, int) (imgui.cpp:5179)
==27446==    by 0x125E59: ImGui::BeginTooltipEx(int, bool) (imgui.cpp:6890)
==27446==    by 0x1947FE: ImGui::ColorTooltip(char const*, float const*, int) (imgui_widgets.cpp:4486)
==27446==    by 0x1945CC: ImGui::ColorButton(char const*, ImVec4 const&, int, ImVec2) (imgui_widgets.cpp:4457)
==27446==    by 0x190FF1: ImGui::ColorEdit4(char const*, float*, int) (imgui_widgets.cpp:3932)
==27446==    by 0x190433: ImGui::ColorEdit3(char const*, float*, int) (imgui_widgets.cpp:3807)
==27446==    by 0x10AC42: main (main.cpp:145)
==27446== 

After some iterations we reach the assert:

ImGui_ImplGlfw_GetWindowPos 0x11a62280  (nil)
example_glfw_opengl3: ../imgui_impl_glfw.cpp:484: ImVec2 ImGui_ImplGlfw_GetWindowPos(ImGuiViewport*): Assertion `data != NULL' failed

@Lecrapouille
Copy link

Lecrapouille commented Oct 5, 2018

@ocornut I did not see your comments when I wrote mine. I gonna try to answer you (I do not know well your code sorry)

@Lecrapouille
Copy link

Lecrapouille commented Oct 5, 2018

note: >>> TRUE is when viewport->PlatformRequestMove = true;
1/

[00113] CreateWindowID 8C2D4FD5  (nil) (nil)
plat = data
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0x11518a60  0x1151c920
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    0x1151c920
[00129] DestroyWindow ID 8C2D4FD5 0x1151c970 0x1151c920
Before ImGui_ImplGlfw_DestroyWindow 0x11518a60  0x1151c920
After ImGui_ImplGlfw_DestroyWindow 0x11518a60  (nil)
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    (nil)
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x11518a60    (nil)
==27931== Invalid read of size 8
==27931==    at 0x12827B: ImGui::UpdateViewports() (imgui.cpp:7458)
==27931==    by 0x11787C: ImGui::NewFrame() (imgui.cpp:3294)
==27931==    by 0x10AB9B: main (main.cpp:127)
==27931==  Address 0x11518a88 is 40 bytes inside a block of size 224 free'd
==27931==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==27931==    by 0x10EB7E: FreeWrapper(void*, void*) (imgui.cpp:992)
==27931==    by 0x11572C: ImGui::MemFree(void*) (imgui.cpp:2815)
==27931==    by 0x145C5C: void IM_DELETE<ImGuiViewportP>(ImGuiViewportP*) (imgui.h:1428)
==27931==    by 0x128276: ImGui::UpdateViewports() (imgui.cpp:7457)
==27931==    by 0x11787C: ImGui::NewFrame() (imgui.cpp:3294)
==27931==    by 0x10AB9B: main (main.cpp:127)
==27931==  Block was alloc'd at
==27931==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==27931==    by 0x10EB60: MallocWrapper(unsigned long, void*) (imgui.cpp:991)
==27931==    by 0x1156D4: ImGui::MemAlloc(unsigned long) (imgui.cpp:2807)
==27931==    by 0x1287C8: ImGui::AddUpdateViewport(ImGuiWindow*, unsigned int, ImVec2 const&, ImVec2 const&, int) (imgui.cpp:7574)
==27931==    by 0x11F563: ImGui::Begin(char const*, bool*, int) (imgui.cpp:5179)
==27931==    by 0x125F01: ImGui::BeginTooltipEx(int, bool) (imgui.cpp:6890)
==27931==    by 0x1948A6: ImGui::ColorTooltip(char const*, float const*, int) (imgui_widgets.cpp:4486)
==27931==    by 0x194674: ImGui::ColorButton(char const*, ImVec4 const&, int, ImVec2) (imgui_widgets.cpp:4457)
==27931==    by 0x191099: ImGui::ColorEdit4(char const*, float*, int) (imgui_widgets.cpp:3932)
==27931==    by 0x1904DB: ImGui::ColorEdit3(char const*, float*, int) (imgui_widgets.cpp:3807)
==27931==    by 0x10AC42: main (main.cpp:145)
==27931== 
IM_DELETE(viewport) 0x11518a60  (nil)
[00131] CreateWindowID 8C2D4FD5  (nil) (nil)
plat = data
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x117832c0    0x11785450
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x117832c0  0x11785450
ImGui_ImplGlfw_GetWindowPos 0x117832c0  0x11785450
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x117832c0    0x11785450
[00133] DestroyWindow ID 8C2D4FD5 0x117854a0 0x11785450
Before ImGui_ImplGlfw_DestroyWindow 0x117832c0  0x11785450
After ImGui_ImplGlfw_DestroyWindow 0x117832c0  (nil)
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0

then several cycles after:

********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
********** ImGui_ImplGlfw_WindowPosCallback
>>> TRUE
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    0x119931b0
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x119910e0  0x119931b0
ImGui_ImplGlfw_GetWindowPos 0x119910e0  0x119931b0
[00177] DestroyWindow ID 8C2D4FD5 0x11993200 0x119931b0
Before ImGui_ImplGlfw_DestroyWindow 0x119910e0  0x119931b0
After ImGui_ImplGlfw_DestroyWindow 0x119910e0  (nil)
ImGui_ImplGlfw_GetWindowPos 0xf635380  0xf6646a0
--------------------
ImGuiViewportP* viewport = g.Viewports[0]; 0xf635380    0xf6646a0
ImGuiViewportP* viewport = g.Viewports[1]; 0x104ed210    0x10503470
ImGuiViewportP* viewport = g.Viewports[2]; 0x119910e0    (nil)
g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable 0x119910e0  (nil)
ImGui_ImplGlfw_GetWindowPos 0x119910e0  (nil)
example_glfw_opengl3: ../imgui_impl_glfw.cpp:491: ImVec2 ImGui_ImplGlfw_GetWindowPos(ImGuiViewport*): Assertion `data != NULL failed.

For me the PlatformUserData is set to NULL in ImGui_ImplGlfw_DestroyWindow then used by ImGui_ImplGlfw_GetWindowPos and not dropped by UpdateViewports inside the for (int n = 0; n < g.Viewports.Size; n++)

PPS: tried to add && viewport->PlatformUserData != NULL to if ((g.IO.ConfigFlags & ImGuiConfigFlags_ViewportsEnable)) this does not help stopping shaking windows :(

@ebachard
Copy link

ebachard commented Oct 16, 2018

Sorry, I don't have much time these days, but I finaly found one hour, and tested the most recent code today. No time to track unfortunaly :-(

Quicly, my configuration is based on Linux Intel x86_64 (+ lot of RAM), HD 620 chipset, gcc-5.4.0 , Linux Mint 18.3 (customized 4.15.18 kernel for uvc 1.5 compatibility) / Gnome Environment
WM : default is compiz + Compton compositor + 3D effects, but I tested as well Metacity + Compton compositor, or Mutter + Compton or even Marco + Compton

What I observed:

Looks like the crash caused by the clear color window, overlaping the main SDL2 window or GLFW Window is not fixed : the crash is still there :-/

Probably a regression : using OpenGL3 + SDL2, or OpenGL3 + GLFW, whatever the WM, I see the following issue : when you drag one window outside the main window, the dragged window seems to flicker once overlaping the main window.

Other issue : when one obrder of the dragged window reaches the border of the screen, the flickering .is triggered

Maybe my imagination, but could there be a race condition between mouse coordinates and window coordinates? The simple trick to stop the ImGui Window to flicker, is to click somewhere inside the main SDL2 or GLFW window. Secondly, I remarked that the ImGui windows always tries to return at its original position, means at the point ( x ~ 50 pixels , y = 50 pixels ) from the Top Left of the main SDL or GLFW window.

Unfortunaly, I didn't make a backup of the previous sources. Got to catch with git to retrieve the old version.

Sorry, got to go. I hope I'll have more time at the end of the week.

HTH

EDIT : I wrongly wrote that the crash was fixed, but it is not in fact ...

@ebachard
Copy link

ebachard commented Oct 17, 2018

For the record, I reproduced the crash with debug enabled, and as expected, there is some null window and coordinates somewhere:


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff00fb700 (LWP 24553)]
[New Thread 0x7fffed9c9700 (LWP 24554)]

Thread 1 "example_sdl_ope" received signal SIGSEGV, Segmentation fault.
0x0000000000403cf5 in ImGui_ImplSDL2_GetWindowPos (viewport=0x456b320) at ../imgui_impl_sdl.cpp:433
433	    SDL_GetWindowPosition(data->Window, &x, &y);
(gdb) p x
$1 = 0
(gdb) p y
$2 = 0
(gdb) p data->Window
Cannot access memory at address 0x0

To reproduce the crash :

  1. compile the example_opengl3 with debug enabled ( -g option for g++ )

If you don't want to build including symbols, just comment the line starting with "DEBUG_FLAGS" (using # character )

@ocornut : in the diff below, I think I corrected a little issue in the Linux Makefile. Precisely, CXXFLAGS = (something) hides the previously defined flags.

diff --git a/examples/example_sdl_opengl3/Makefile b/examples/example_sdl_opengl3/Makefile
index 6987411..1786a67 100644
--- a/examples/example_sdl_opengl3/Makefile
+++ b/examples/example_sdl_opengl3/Makefile
@@ -20,7 +20,7 @@ SOURCES += ../imgui_impl_sdl.cpp ../imgui_impl_opengl3.cpp
 SOURCES += ../../imgui.cpp ../../imgui_demo.cpp ../../imgui_draw.cpp ../../imgui_widgets.cpp
 OBJS = $(addsuffix .o, $(basename $(notdir $(SOURCES))))
 UNAME_S := $(shell uname -s)
-
+DEBUG_FLAGS = -g
 ##---------------------------------------------------------------------
 ## OPENGL LOADER
 ##---------------------------------------------------------------------
@@ -45,8 +45,8 @@ CXXFLAGS = -I../libs/gl3w
 ifeq ($(UNAME_S), Linux) #LINUX
        ECHO_MESSAGE = "Linux"
        LIBS = -lGL -ldl `sdl2-config --libs`
-
-       CXXFLAGS = -I../ -I../../ -I../libs/gl3w `sdl2-config --cflags`
+       CXXFLAGS += ${DEBUG_FLAGS}
+       CXXFLAGS += -I../ -I../../ -I../libs/gl3w `sdl2-config --cflags`
        CXXFLAGS += -Wall -Wformat
        CFLAGS = $(CXXFLAGS)
 endif

  1. run the debugger
 gdb64 --args ./example_sdl_opengl3
  1. Drag the Hello window at the bottom of the main window (just put it at the border, no need to overlap)
  2. click on clear color.

Expected : should open the colorpicker

  1. Once the colorpicker is open, move its window to overlap the main window.

  2. Then, move the mouse cursor inside the colorpicker window, exactly over "Original" color rectangle.
    Once over this area, another rectangle box opens (probably a tooltip ?)
    If the tooltip rectangle overlaps the main window, the crash occurs.
    (oppositely : it the tooltip rectangle appears inside the main window, no crash).

This crash is 100% reproductible, and I think some new windows are uninitialized, or lost their position, but I can be wrong.

Last but not least : english is not my native language, so feel free to correct me. TIA :-)

@Lecrapouille
Copy link

@ebachard You confirmed what I noticed.

I do not understand well the code but all I what I could traced is PlatformUserData is set to NULL in ImGui_ImplGlfw_DestroyWindow then used by ImGui_ImplGlfw_GetWindowPos and not dropped by UpdateViewports inside the for (int n = 0; n < g.Viewports.Size; n++) and the segfault occurs when accessing to the NULL pointer. This is what you can read in my looooong logs :)

For me is not a platform specific issue because the code is the same for all archi. I think it's most an algorithm issue or race condition between the 2 threads. But I do not understand the whole code so I cannot help more. Anyway I'm not sure this is related with flickering effects.

Did you try with valgrind ? It detects a memory corruption before the segfault occurs (which comes randomly but several cycles after). You can use rr (record & replay) which record the execution and call gdb (unfortunately I cannot use it with my Ryzen CPU).

If this can help: to trace stack, I use backward. Here the Makefile to change (also working for Darwin, never tested on Windows):

	SOURCES = backward.cpp main.cpp

	LIBS = -lGL `pkg-config --static --libs glfw3` -ldw
	CXXFLAGS += -I../ -I../../  `pkg-config --cflags glfw3` -DBACKWARD_HAS_DW=1
	CXXFLAGS += -Wall -Wformat -O2 -g -fomit-frame-pointer
	CFLAGS = $(CXXFLAGS)

You have to add in Makefile the file backward.cpp the library -ldw the define -DBACKWARD_HAS_DW=1 gcc options -O2 -g -fomit-frame-pointer and maybe to do apt-get install libdw-dev

I've truncated the bug report (after the crash) but there the stack calls (which rephrases what we wrote):

ImGui::NewFrame();
UpdateViewports();
viewport->Pos = g.PlatformIO.Platform_GetWindowPos(viewport);
glfwGetWindowPos(data->Window, &x, &y);

@Alzathar
Copy link
Contributor

Alzathar commented Oct 20, 2018

The following message is to report the macOS compatibility of the viewport branch using the example_glfw_opengl3binary.

  • OS: macOS 10.12.6
  • Hardware: MBA Late 2013
  • ImGui version: 1.66 WIP (056af2b)
  • GLFW version: 3.2.1 and 3.3.0

  • Crash encountered: none

  • Issue encountered:

    1. The created child viewport gains the focus and it is no more possible to move it outside of the main viewport. It is necessary to release the LMB, press it again on the child viewport to move it completely outside of the main viewport.
      imgui-viewport-example-glfw-opengl3-reduced

    2. When resizing a child viewport (from the bottom-right corner or the top and bottom edges), this one jumps (possible rounding error?). Note: in the following GIF, the child viewport has no problem to move outside of the main viewport because the fix proposed in the next section was applied.
      imgui-viewport-example-glfw-opengl3 nofocus_on_show-resize-glitch-reduced

  • Possible fix

    1. No way was found with GLFW 3.2.1. However, GLFW 3.3 introduced a new window attribute that fixes this problem: GLFW_FOCUS_ON_SHOW. I tested it (see the commit Alzathar@d560773 for the modifications in example_glfw_opengl3) and the child viewport can move without problem. This code was also tested without problem under Windows 10. Unfortunately, this may introduce another problem. Indeed, as explained in the commit, the previous viewport keep the focus. Supplementary code is needed to give to the child viewport the focus when the user stops to move it and release the LMB. Is it a problem or not?
      imgui-viewport-example-glfw-opengl3 nofocus_on_show-reduced

@ebachard
Copy link

@Alzathar : can you please confirm the crash we decribed with @Lecrapouille (the clear color one) doesn't occur on Mac OS X ?

TIA

@Alzathar
Copy link
Contributor

Alzathar commented Oct 21, 2018

@ebachard On macOS, I have not the segfault reported in this comment #1542 (comment)

imgui-viewport-example-glfw-openg_macos_hello-color

I tried with other configurations (hello world window in a child viewport, color picker in another child viewport when appearing, main viewport without window), and there is no segfault. However, I found one minor issue when a window is in a child viewport and is collapsed and then expanded. When expanded, the window moves to the top of the screen, expand, and then moves to the previous position. Note: in the following GIF, the expanded window seems to move to the top only the first time it is collapsed and expanded, but that is not the case. This is a problem with the screen recording at 15FPS. Each time you collapse and expand a window, this one moves to the top.

imgui-viewport-example-glfw-openg_macos_hello-color-outside

@Lecrapouille
Copy link

I do not have OSX now, can you try moving your mouse like on this video (sorry my video is not nice : the "clear color" window is not appearing because of the gif recorder grabbing the focus):
crash

@ebachard
Copy link

@Alzathar : sorry, my explanation was probably unclear. I'll try using other words:

The main point is: open an openGL child window outside of the main window (a glfwWindow for you, if I'm not wrong). To respect this test case, you'll have to put the Hello window near to the inside border of the glfw Window. Then, move the cursor over the "Original" visual, in order to make the tooltip rectangle appear with one part inside and one part outside of the main glfw Windows (in your last gif, the hello window is already outside the main glfw Window, and this is another test case).

The example we propose uses the clear color, based on the Hello window, but I'll try to find another example, to try to isolate the reason (the "WHY" ). The "WHAT" being the crash, caused by null coordinates.

@Lecrapouille: I think your idea is interesting, and maybe the flickering could be caused by some rounding issue (or something similar). But I need to find the time to debug (not before next friday, sorry). Last but not least, thank yu very much for the valgrind tips. I'm used to gdb, but I'll git valgrind a try, of course.

@Alzathar
Copy link
Contributor

Alzathar commented Oct 21, 2018

@Lecrapouille I tried like in your video (switching quickly between the hello window and the clear color window) and I have no segfault. @ebachard I also reproduced the steps detailed in #2117 (comment), but there is no segfault either.

I think we can say this crash is only related to Linux. Based on what I read in this discussion, there are different versions of Linux, different GPUs (Ryzen, Intel), different WMs (compositing or tiling), different backends (GLFW, SDL2) and maybe different versions of the viewport branch of Dear ImGui. If I read correctly, the crash happens in all configuration with compositing WM. However, it is not confirmed with the i3 tiling manager (@s-ol did you have a crash for the sdl_opengl3 example under i3?). It is not yet clear for me if the problem is related to the WM or Dear ImGui. Because compositing WM does supplementary processing when a window is created and destroyed, the problem might be related to the speed of the WM to process the request sent by Dear ImGui to create a window. An idea would be to assert the result of the glfwCreateWindow function in the example_gflw_opengl3 (line 388). You could add the line assert(data->Window) to verify if the window is correctly created.

@Lecrapouille
Copy link

You should try this.

glfwCreateWindow is not the cause. I added assert(data->Window) and this does not crash. I persist to say the only cause is made by this line where NULL pointer is used. Finding why it's still used will fix your issue. If you want a quick & dirty workaround add && viewport->PlatformUserData != NULL in the if of this line this fix the segfault but not the flickering effect.

@Lecrapouille
Copy link

Lecrapouille commented Oct 21, 2018

I tried with example_sdl_opengl3 for Linux (I did not before) I have no issue (not flickering, no segfault, no NULL pointer in my trace). The only drawback I noticed is that I loose the mouse focus on firefox, Linux console ... I cannot use the keyboard (like entering this issue for example).
crash2

I tried to diff code source SDL vs GLFW. I noticed a minor error:
SDL: bool err = gladLoadGL() == 0; vs GLFW: bool err = gladLoadGL() != 0; in main.cpp
and SDL have a little more checks against NULL (for example data->Window && missing in ImGui_ImplGlfw_DestroyWindow)

@ebachard
Copy link

@Alzathar : sorry, I was afk all the week, but I found some time to check back at home. Indeed, you are right : the crash on Linux is very probably caused by the compositing. Once it (the compositing) is disabled, the crash previously mentionned does no longer occur.

Other test without window compositing on Linux (i.e. it is disabled): After some tries, remains one last issue : when I move an ImGui window outside of the main SDL_Window (or GLFW window depending on your choice), the ImGui window is stuck on the border, and cannot go out (and partially disappear).

Can someone confirm there is something similar ?

@Lecrapouille
Copy link

Lecrapouille commented Nov 1, 2018

@Alzathar : I cannot help you: I have not this effect either on SFWL or SDL opengl3 + Debian 64bits (libSDL2-2.0.so.0.8.0, libglfw.so.3.2). I think people have different versions of these libs that may explain these different behaviors.

I just noticed a new glitch with Imgui imgui SDL + XFCE that I cannot record in gif.

When the panel color is outside, I see blinking effect on buttons of the XFCE docker. Buttons which correspond to imgui windows and their child. The blinking can be explained by:

  • the main window is releasing the docker button, then the child window is taking it
  • then the contrary: child releasing ...
    This is due to the frequency where they are painted.

Therefore once a child is outside its main window, you cannot longer use your mouse for inserting texts in other XFCE applications (firefox, console, emacs ...) its like the child windows is placed on the top of all XFCE applications which lost their mouse focus and you no longer can type on them. See my previous gif screenshot about it (upper in this post).

Finally, when changing of virtual desktop, child windows are following the new desktop and displayed on the new one (while the main window is still present on the previous desktop). With the same effect (docker blinking + no mouse focus).

@BrutPitt
Copy link

BrutPitt commented Nov 7, 2018

For first thing: great job... and the multiple viewports is very very amazing!

I tested ImGui 565af90 in my application that use GLFW and OpenGL

On Linux and Window the program use AZDO (Approaching Zero Driver Overhead), functions available from OpenGL 4.5
In Mac OS X, for limitation of the OS, I have used the OpenGL 4.1 functionalities
I did only tests to 64 bits for OSs and application.

I tested it on Linux (Fedora 28 and Ubuntu 18.04.1 LTS), OS X 10.14 (Mojave), Windows 10, and also WINE 3.14 under Linux
The analysis of the results is shown below.
I add links to the movies of the screen captures (each few seconds): is easier to understand what I'm talking about.
I'm sorry for the animated gif, but I have captured large portions of the screen.

OS: Fedora 28
GPU: Intel HD 530
WM: Metacity
(no effect, no compiz)

https://youtu.be/ghIv3xocev0

About the ColorEdit box problem, I noticed that when shows the coloredit popup, appear a new "Untitled Window" on task bar.
(The ImGuiConfigFlags_ViewportsNoTaskBarIcon flag: on linux do not works.)
After begin a rebound of the popup window between the main viewport (top left corner) and the correct position on desktop (near to color edit box) and continue until I move the mouse...and when the mouse left the box, few istants and the application crashes.

OS: Fedora 28
GPU: Intel HD 530
WM: Metacity
(no effect, no compiz)

https://youtu.be/HLCyDMQmzYU

The ImGuiConfigFlags_ViewportsNoTaskBarIcon flag: on linux do not works
Same thing with a simple text popup (like helper (?) function of imgui_demo): "Untitled window" on task bar, but no rebounds on main Viewport (perhaps because there is not a texture like in coloredit?)
when i move away the mouse the application crashes, same as for the ColorEdit

OS: Fedora 28
GPU: Intel HD 530
WM: Metacity
(no effect, no compiz)

https://youtu.be/yZVxy6MEE_I

There is a problem also when I resize a window near edge of screen (Desktop): when i reach the border, the window increases on the opposite side:

OS: Ubuntu 18.04.1 LTS
GPU: AMD RX 480
WM: Metacity
(no effect, no compiz)

https://youtu.be/fin6E3pIjJA

Strange rebound between main viewport and desktop when I reach the border of screen (desktop) with the window (also in Fedora).
And also here, as in fedora, when it comes out of the main viewport: the main window (with main viewport) lose the focus, and the mouse lose the drag from the new created window: here GLFW_FOCUS_ON_SHOW do not works.

OS: Wine 3.14 under Fedora 28
GPU: Intel HD 530
WM: Wine 3.14 under Metacity
(no effect, no compiz)

https://youtu.be/4imddy_QeTI

I tested Win64 executables on wine 3.14, under Fedora 28, with OpenGL 4.5.
Here on linux, where crashes often, with wine run very fluid: no crash and no big problems (In wine, like in Windows, ImGuiConfigFlags_ViewportsNoTaskBarIcon works, obviously) .
It Works like in Windows 10: same behaviour. (look below, last test)

OS: OS X 10.14 (Mojave)
GPU: AMD RX 480

https://youtu.be/jKg9yjDiZUk

The app is functional: no crash.
Minor troubles:
Same issue on resize as marked from Alzathar and others.
GLFW_FOCUS_ON_SHOW works well on move the window from main viewport to outside, but outside, the inactive window, need TWO click to get focus: with the first it come topmost, with second get the focus.
Here, on the taskbar, you only see the main program icon with or without ImGuiConfigFlags_ViewportsNoTaskBarIcon.

OS: Windows 10.
GPU: NVidia RTX 2070

https://youtu.be/boL63aLjANk

The app is almost perfect: I used it for a long time an works fine, no crashes, no errors!
Only thing I noticed, when I step on the ColorEdit box (in a window outside main viewport) with the mouse, the popup appear for an istant on main viewport (top left corner), like in linux, but only once, for very few frames,

vlcsnap-2018-11-07-08h11m18s596

and after it is positioned in the correct position.

vlcsnap-2018-11-07-08h11m47s540

It does it again if I move the mouse and reposition it.
On RTX 2070 is very rapid, the movie capture do not catch it all times

That's all.
If I need more tests, particular outputs, or anything else, I will be happy to be useful.

Michele

@ocornut
Copy link
Owner Author

ocornut commented Nov 7, 2018

Thank @BrutPitt for your reports and all the details. It will take me a while to get through all the stuff in this thread and I'll probably need to obtain Mac/Linux machines to make more sensible possible on many of those machines.

@BrutPitt
Copy link

BrutPitt commented Nov 27, 2018

This weekend, with some time available, I did some tests/debug on linux.
If it could be useful: the application crash on the ColorEdit box popup window, in the ImGui_ImplGlfw_GetWindowPos(ImGuiViewport* viewport) function of imgui_impl_glfw.cpp file (line:504), when call glfwGetWindowPos(data->Window, &x, &y);

static ImVec2 ImGui_ImplGlfw_GetWindowPos(ImGuiViewport* viewport)
{
    ImGuiViewportDataGlfw* data = (ImGuiViewportDataGlfw*)viewport->PlatformUserData;
    int x = 0, y = 0;
    glfwGetWindowPos(data->Window, &x, &y);
    return ImVec2((float)x, (float)y);
}

because data == NULL

Calls stak

ImGui_ImplGlfw_GetWindowPos imgui_impl_glfw.cpp:504
ImGui::UpdateViewports imgui.cpp:7303
ImGui::NewFrame imgui.cpp:3307
mainImGuiDlgClass::renderImGui uiMainDlg.cpp:1945
mainGLApp::mainLoop glApp.cpp:502
main glApp.cpp:540
__libc_start_main 0x00007ff29e79e11b
_start 0x00000000004086da

(This happens occasionally, almost infrequently, not in every call)

If I use:

if(data && data->Window) glfwGetWindowPos(data->Window, &x, &y);

the application does not crash anymore, nor with the ColorEdit popup, nor with any other popup.
But I guess that we must understand why data==NULL.

@ebachard
Copy link

ebachard commented Dec 2, 2018

Little update:

Using up-to-date viewport branch
Processor : Intel x86_64
Linuxmint 18.3
using SDL2 + OpenGL3
WM : Gnome + Compiz compositor

I just wanted to add, that there is no more crash with recent changes. Thanks @ocornut !

Remain the window dancing when moving close to the limit of the main window. After some tries, it appears that:

  • moving the window very slowly close to the border of the main window does not cause the issue
  • moving horizontaly causes horizontal danse issue only
  • same issue : moving the ImGui window out of the main SDL window verticaly causes a vertical dance only when close to the border.

Once out of the main window : no problem.

Last but not least : same issue with other window manager ( e.g. metacity without compositor)

@ocornut : I think you are very close to something working well.

@ocornut
Copy link
Owner Author

ocornut commented Dec 3, 2018

Everyone on SDL, can you try replacing the code that sets the io.MousePos to use the absolute mouse coordinates without a back and forth:

e.g in imgui_impl_sdl.cpp

    SDL_Window* focused_window = SDL_GetKeyboardFocus();
    if (focused_window)
    {
        // SDL_GetMouseState() gives mouse position seemingly based on the last window entered/focused(?)
        // The creation of new windows at runtime and SDL_CaptureMouse both seems to severely mess up with that, so we retrieve that position globally.
        int wx, wy;
        SDL_GetWindowPosition(focused_window, &wx, &wy);
        SDL_GetGlobalMouseState(&mx, &my);
        mx -= wx;
        my -= wy;
    }
    if (ImGuiViewport* viewport = ImGui::FindViewportByPlatformHandle((void*)focused_window))
        io.MousePos = ImVec2(viewport->Pos.x + (float)mx, viewport->Pos.y + (float)my);

Change to

    SDL_Window* focused_window = SDL_GetKeyboardFocus();
    if (focused_window)
    {
        // SDL_GetMouseState() gives mouse position seemingly based on the last window entered/focused(?)
        // The creation of new windows at runtime and SDL_CaptureMouse both seems to severely mess up with that, so we retrieve that position globally.
        SDL_GetGlobalMouseState(&mx, &my);
    }
    if (ImGuiViewport* viewport = ImGui::FindViewportByPlatformHandle((void*)focused_window))
        io.MousePos = ImVec2((float)mx, (float)my);

And for GLFW in imgui_impl_glfw.cpp you may try to change

double mouse_x, mouse_y;
glfwGetCursorPos(window, &mouse_x, &mouse_y);
io.MousePos = ImVec2((float)mouse_x + viewport->Pos.x, (float)mouse_y + viewport->Pos.y);

to

double mouse_x, mouse_y;
int window_x, window_y;
glfwGetCursorPos(window, &mouse_x, &mouse_y);
glfwGetWindowPos(window, &window_x, &window_y);
io.MousePos = ImVec2((float)mouse_x + (float)window_x, (float)mouse_y + (float)window_y);

@ocornut
Copy link
Owner Author

ocornut commented May 8, 2021

This has been the main issue on Linux for 2 years (many reports above are variations of that) and somehow nobody went through to submit a proper fix for it yet (i am not a linux user).

There’s however a variant of this which is more puzzling, according to @rokups apparently when dragging windows partly outside of screen boundaries, the WM clamp them within boundaries but the corresponding getter functions in GLFW/SDL return the values requested in the setter functions (so without clamping). This may depend on the WM thought. @rokups could you check on Daniel’s suggestion to rework the linked code above and see if we can rely on the callback values instead of the explicit getter call?

If your fix works for you this is good news. How does the interaction feels? At which points does the mouse stops mapping to window position and can you extract it back properly?

@emoon
Copy link
Contributor

emoon commented May 8, 2021

So in my case I plan to use floating windows only so placing a child window on top of the main window will not "put it back" inside the main one. I also have docking disabled. What I plan to do is that child windows will "stick" on the sides of the main one.

So for this my local change seems it work fine, but I'm not sure if the fix that is needed for all other cases.

@emoon
Copy link
Contributor

emoon commented May 11, 2021

im_hippo

Just for reference this is what I'm hacking around with. I'm exploring to switch form Qt to bgfx/dear imgui for my musicplayer. This UI here is just a mock-up, but have the ability now to use multiple windows which is something I really needed and it works good in my case as I always have everything "floating"

@rokups
Copy link
Contributor

rokups commented Jun 1, 2021

@rokups could you check on Daniel’s suggestion to rework the linked code above and see if we can rely on the callback values instead of the explicit getter call?

We still can not drag a window outside of screen rect using glfwSetWindowPos() and callback correctly reports window position as "stuck" at the edge, however if window is moved outside of screen bounds using meta|alt+drag WM shortcut - callback does report correct positions. Seems like we have a path to better handling this situation, until SDL/GLFW produce a fix allowing to drag windows outside of screen bounds. 👍🏻

@exuvo
Copy link

exuvo commented Dec 14, 2021

We still can not drag a window outside of screen rect using glfwSetWindowPos() and callback correctly reports window position as "stuck" at the edge, however if window is moved outside of screen bounds using meta|alt+drag WM shortcut - callback does report correct positions. Seems like we have a path to better handling this situation, until SDL/GLFW produce a fix allowing to drag windows outside of screen bounds. 👍🏻

I'm not sure if this has been fixed since your comment but i don't seem to have any problems with dragging main viewport window or platform windows outside my monitors visible area. Maybe i misunderstand what the problem is?

Using GLFW backend patched to handle multiple main viewports. On Arch Linux with X and openbox window manager.

@mgerhardy
Copy link

mgerhardy commented Jan 3, 2022

I had to adopt the sdl backend code for the mouseglobalstate and viewports disabled code path.

The problem was, the the window position by sdl is reported as x-offset 2560 - the global mouse coordinate was e.g. 956

It is possible that this is due to my xrandr config:

Screen 0: minimum 16 x 16, current 5120 x 1440, maximum 32767 x 32767
XWAYLAND27 connected 2560x1440+0+0 (0x24) normal (normal left inverted right x axis y axis) 600mm x 340mm
	Identifier: 0x6d3
	Timestamp:  38592
	Subpixel:   unknown
	Gamma:      1.0:1.0:1.0
	Brightness: 0.0
	Clones:    
	CRTC:       1
	CRTCs:      1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	non-desktop: 0 
		supported: 0, 1
  2560x1440 (0x24) 312.000MHz -HSync +VSync *current +preferred
        h: width  2560 start 2752 end 3024 total 3488 skew    0 clock  89.45KHz
        v: height 1440 start 1443 end 1448 total 1493           clock  59.91Hz
XWAYLAND28 connected primary 2560x1440+2560+0 (0x24) normal (normal left inverted right x axis y axis) 600mm x 340mm
	Identifier: 0x6d5
	Timestamp:  38592
	Subpixel:   unknown
	Gamma:      1.0:1.0:1.0
	Brightness: 0.0
	Clones:    
	CRTC:       0
	CRTCs:      0
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	non-desktop: 0 
		supported: 0, 1
  2560x1440 (0x24) 312.000MHz -HSync +VSync *current +preferred
        h: width  2560 start 2752 end 3024 total 3488 skew    0 clock  89.45KHz
        v: height 1440 start 1443 end 1448 total 1493           clock  59.91Hz
diff --git a/backends/imgui_impl_sdl.cpp b/backends/imgui_impl_sdl.cpp
index f87393f5..b90eaff2 100644
--- a/backends/imgui_impl_sdl.cpp
+++ b/backends/imgui_impl_sdl.cpp
@@ -408,6 +408,16 @@ static void ImGui_ImplSDL2_UpdateMousePosAndButtons()
             // Unlike local position obtained earlier this will be valid when straying out of bounds.
             int window_x, window_y;
             SDL_GetWindowPosition(mouse_window, &window_x, &window_y);
+            int display_index = SDL_GetWindowDisplayIndex(mouse_window);
+            SDL_Rect display_rect;
+            SDL_GetDisplayBounds(display_index, &display_rect);
+            SDL_Point mouse_coord_point;
+            mouse_coord_point.x = mouse_x_global;
+            mouse_coord_point.y = mouse_y_global;
+            if (!SDL_PointInRect(&mouse_coord_point, &display_rect)) {
+                windowX -= display_rect.x;
+                windowY -= display_rect.y;
+            }
             io.MousePos = ImVec2((float)(mouse_x_global - window_x), (float)(mouse_y_global - window_y));
         }
     }

Even if it works with my current monitor setup - it's most likely not correct. (also SDL function return values are not checked for errors here)

without this offset hack the application was started at SDL display 0 - but the mouse movement was only caught while being on display 1 (right next to SDL display 0)

EDIT:

the window (0:0) the mouse is hovering is on SDL display 0 (0:0:2560:1440), but the global mouse position is at 3646:769 - this looks like a bug in SDL for me. I will report it there. Weird thing is that the SDL display 1 has a x position of 2560 but is the left display. Not sure how to convert the mouse coordinates properly.

@andreagen0r
Copy link

Hi, I'm getting some issues with the docking branch on Ubuntu X11.
I just run the example_glfw_opengl3.
The docking area appears to be offset when dragging over.
Sometimes the window cannot be moved before resized
Sometimes delete key does not work on text input

Version: 1.87
Branch: docking

Back-ends: OpenGL
Compiler: GCC 10.3.0
Operating System: Ubuntu 20.04

video

@maksym-pasichnyk
Copy link

Hi, I have some issues on MacOS with Vulkan backend.
When window is collapsed, ImGui::WindowSyncOwnedViewport() enable ImGuiViewportFlags_NoRendererClear flag, and platform window not clearing

void ImGui::WindowSyncOwnedViewport(...) {
    ...
    // We can also tell the backend that clearing the platform window won't be necessary,
    // as our window background is filling the viewport and we have disabled BgAlpha.
    // FIXME: Work on support for per-viewport transparency (#2766)
    if (!(window_flags & ImGuiWindowFlags_NoBackground))
        viewport_flags |= ImGuiViewportFlags_NoRendererClear;
    ...
Screen.Recording.2022-05-05.at.17.21.54.mov

@maksym-pasichnyk
Copy link

If enable 'No background' checkbox in demo window, this issue appears too

Screen.Recording.2022-05-05.at.17.38.53.mov

Hi, I have some issues on MacOS with Vulkan backend. When window is collapsed, ImGui::WindowSyncOwnedViewport() enable ImGuiViewportFlags_NoRendererClear flag, and platform window not clearing

void ImGui::WindowSyncOwnedViewport(...) {
    ...
    // We can also tell the backend that clearing the platform window won't be necessary,
    // as our window background is filling the viewport and we have disabled BgAlpha.
    // FIXME: Work on support for per-viewport transparency (#2766)
    if (!(window_flags & ImGuiWindowFlags_NoBackground))
        viewport_flags |= ImGuiViewportFlags_NoRendererClear;
    ...

Screen.Recording.2022-05-05.at.17.21.54.mov

@InvalidUsernameException

The multi-viewport feature is somehow causing my X server to crash.

Environment:

  • Arch Linux 5.15.81 LTS kernel
  • X Server 1.21.1.4
  • i3wm 4.21.1
  • Intel® HD Graphics 4000 (from an i5-3230M)
  • Dear ImGui commit 3ea0fad

Steps:

  1. Start one of the examples. I've tried example_glfw_opengl3, example_glfw_opengl2, example_sdl_opengl3 and example_sdl_opengl2.
  2. Pull one of the sub windows out of the main window.
  3. Put the windows that was pulled out into full screen mode (Mod+F keybind be default).
  4. Exit full-screen mode (Mod+F again).

On step 4 the whole X server crashes. In the X server log file I can find the following stack trace:

[  4330.703] (EE) Backtrace:
[  4330.704] (EE) 0: /usr/lib/Xorg (dri3_send_open_reply+0xdd) [0x5566b6bd9bad]
[  4330.705] (EE) 1: /usr/lib/libc.so.6 (__sigaction+0x50) [0x7f9f9f5a7a00]
[  4330.705] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  4330.706] (EE) 2: /usr/lib/xorg/modules/drivers/intel_drv.so (?+0x0) [0x7f9f9e7fc6ca]
[  4330.706] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  4330.706] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (?+0x0) [0x7f9f9e88b558]
[  4330.707] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  4330.707] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (?+0x0) [0x7f9f9e801ffa]
[  4330.707] (EE) 5: /usr/lib/Xorg (DamageDamageRegion+0x1e0) [0x5566b6b4d650]
[  4330.707] (EE) 6: /usr/lib/Xorg (SetRootClip+0xb8f) [0x5566b6b2d49f]
[  4330.708] (EE) 7: /usr/lib/Xorg (SetRootClip+0x366c) [0x5566b6b2ff7c]
[  4330.708] (EE) 8: /usr/lib/Xorg (SetRootClip+0x4365) [0x5566b6b30c75]
[  4330.708] (EE) 9: /usr/lib/Xorg (FreeAllResources+0x4f2) [0x5566b6b22542]
[  4330.708] (EE) 10: /usr/lib/Xorg (MapWindow+0x164) [0x5566b6b280d4]
[  4330.709] (EE) 11: /usr/lib/Xorg (UpdateCurrentTime+0x8db) [0x5566b6af0c0b]
[  4330.709] (EE) 12: /usr/lib/Xorg (SProcXkbDispatch+0x280c) [0x5566b6aba057]
[  4330.710] (EE) 13: /usr/lib/libc.so.6 (__libc_init_first+0x90) [0x7f9f9f592290]
[  4330.711] (EE) 14: /usr/lib/libc.so.6 (__libc_start_main+0x8a) [0x7f9f9f59234a]
[  4330.711] (EE) 15: /usr/lib/Xorg (_start+0x25) [0x5566b6aba475]
[  4330.711] (EE) 
[  4330.711] (EE) Segmentation fault at address 0x20
[  4330.711] (EE) 
Fatal server error:
[  4330.711] (EE) Caught signal 11 (Segmentation fault). Server aborting

Based on the Intel graphics driver code in the stack trace I've tried the same using the discrete graphics card (from Nvidia) instead. There I cannot reproduce the crash.

Also worth noting: The crash only happens with the windows form the multi-viewport stuff. Fullscreening and restoring the main window of the example does not cause problems.

Now I'm just a user of Dear ImGui based software, so I don't really know what to do with this. It obviously seems to be Intel specific, but I don't know how to determine where the bug belongs to. As far as I can tell it could be Dear ImGui, i3, the X Server, the graphics driver or any combination of them.

@Casqade
Copy link

Casqade commented Apr 5, 2023

Looks like tooltips/popups get recreated on contact with window border. I understand the intention behind this behaviour, but it breaks drag & drop functionality (example below). Is there an option to confine such widgets to platform window or force the behaviour from non-docking branch ?

Environment:

  • Arch Linux 6.2.9-arch1-1
  • GNOME 43.4
  • Mutter 43.4-1
  • Mesa 23.0.1 (Intel)

Software:

GLFW + OpenGL3 demo:

demo.webm

Unfortunately, mouse cursor is not captured by screencast software... I hope the example shows how dragged grid items disappear and how hard it is to initiate drag & drop on color widgets.

The same example works without problems on Windows 10, so I dedided to dicsuss the issue here

@neoedmund
Copy link

neoedmund commented Aug 11, 2023

Window shakes when moving
Linux X11 xfce4 SDL2+vulkan

m3.webm

Reason: I guess there are internally multiple windows for a single window, and their positions vary, and the events are all passed in. the solution should filter out the messages of the correct window.

@ocornut
Copy link
Owner Author

ocornut commented Dec 12, 2023

I guess this could be helpful if implemented in GLFW:
glfw/glfw#2437

@deblvrs
Copy link

deblvrs commented Dec 24, 2023

i dont know how to do this on mac can someone help

@Daedie-git
Copy link

Daedie-git commented May 11, 2024

@

This has been the main issue on Linux for 2 years (many reports above are variations of that) and somehow nobody went through to submit a proper fix for it yet (i am not a linux user).

There’s however a variant of this which is more puzzling, according to @rokups apparently when dragging windows partly outside of screen boundaries, the WM clamp them within boundaries but the corresponding getter functions in GLFW/SDL return the values requested in the setter functions (so without clamping). This may depend on the WM thought. @rokups could you check on Daniel’s suggestion to rework the linked code above and see if we can rely on the callback values instead of the explicit getter call?

If your fix works for you this is good news. How does the interaction feels? At which points does the mouse stops mapping to window position and can you extract it back properly?

Hi,

I'm interested in contributing to solving some of these problems. i've made a summary video of the issues I'm looking into atm:

Screencast.from.05-11-2024.02.19.13.PM.webm

To summarize:
Window/Viewport take charge in determining position and assume that our native window follows suit. This works on some platforms, but not on others. That leads to these behaviors:
- jittering of ForegroundDrawList content when hovering seperated viewports over each other (Maybe background too?).
- Foreground content keeps moving even though the viewport is clamped to the desktop.
- Interacting with viewports that have clamped to a desktop edge breaks because the window is assumed to be in a different position.

I tried reproducing this problem with the demo using a (linux, SDL, opengl) and a (linux, glfw, opengl) config and the jittery part is almost completely non-existent for SDL. I looked into the window positioning code and SDL will actually wait for the window manager to accept the new position before returning, glfw does not, explaining the difference there.

What I haven't been able to figure out yet, is why the window content is always positioned correctly, but the Foreground content is not. I expect it would be either both or neither since it all comes down to rendering on a viewport. If someone could enlighten me on that, that could be quite helpful.

I can think of 2 approaches here:

  1. I could create a repo of a demo windows build that emulates the linux behavior. Creating a reproducing scenario for the maintainers to work with.
  2. I could look into fixing it myself. But I'll need some support.

@ocornut
Copy link
Owner Author

ocornut commented May 11, 2024 via email

@Daedie-git
Copy link

Hi,

I did some experimenting and have some things to share:

  • I was able to clamp the window to the desktop by changing UpdateMouseMovingWindowNewFrame() to use the PlatformIO callbacks to set and retrieve the window position in case of a viewportOwned window. I expect that similar changes would have to be made in different places as well. I'm a little on the fence about this change though, it kind of feels like some more structural change is needed here to have this happen in a single place.
  • The overlay desync looks like it will be hard to solve well. The latest time we can determine the actual position of the window is right before presenting, but the time of presenting is not the same as the time of drawing, while we're waiting for our frame to actually get rendered, the window can keep moving.
    -> I tried experimenting with replacing the DisplayPos from the ImDrawData with the actual window position at that time. That had interesting results (i could actually move the imgui window offscreen now as expected). But the imgui windows then desyncs from the real windows. I then tried to see if I could alleviate this by creating bigger windows with transparent framebuffers, but that window setting didn't seem to work at all for my window manager.
    -> An idea that I didn't experiment with at all yet. Would it be possible to use the native decoration (and style it?). It seems to be way more responsive then programmatically positioning a window.
    -> The SDL approach of waiting for the windows position to update is always an option I guess? But it might end up causing different (and worse) problems then the ones we have now.

It kind of feels like what you actually would want is a separate transparent overlay window on top the one that is going to be docked to, but then the transparent framebuffer thing would get in the way again. I guess it could be like an optional configuration thing that could be enabled when the support is there.

Not sure if any of this is new to you, but I'd rather overshare than undershare.

@JaoSchmidt
Copy link

JaoSchmidt commented Aug 18, 2024

I'm not sure if my experience will be helpful since this issue is open for quite a while.

I discover that switching my integrated video card with my dedicated video card solves the out-of-window shacking.

Notebook: 550XDA P17CFB
CPU: 11th Gen Intel i5-1135G7 (8) @ 4.200GHz
DE: Xfce 4.18

Integrated video card
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.1-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.1-arch1.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.1-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

without.prime-run.mp4

Dedicated video card
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce MX450/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 550.90.07
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 550.90.07
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 550.90.07
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

with.prime-run.mp4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests