imgui
imgui copied to clipboard
ocornut
Linux/Mac compatibility of multi-viewports
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.
The discussions involving @Ylannl @ebachard, @s-ol, @Lecrapouille starts around here: https://github.com/ocornut/imgui/issues/1542#issuecomment-426918984
:+1:
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).
@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/
@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);
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
@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)
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 :(
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 ...
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 :
- 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
- run the debugger
gdb64 --args ./example_sdl_opengl3
- Drag the Hello window at the bottom of the main window (just put it at the border, no need to overlap)
- click on clear color.
Expected : should open the colorpicker
-
Once the colorpicker is open, move its window to overlap the main window.
-
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 :-)
@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);
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:
-
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.
-
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.
-
-
Possible fix
- 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 https://github.com/Alzathar/imgui/commit/d56077359fac5b6934604f47e27181a7898a5732 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?
- 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 https://github.com/Alzathar/imgui/commit/d56077359fac5b6934604f47e27181a7898a5732 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?
@Alzathar : can you please confirm the crash we decribed with @Lecrapouille (the clear color one) doesn't occur on Mac OS X ?
TIA
@ebachard On macOS, I have not the segfault reported in this comment https://github.com/ocornut/imgui/issues/1542#issuecomment-427122576
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.
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):
@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.
@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 https://github.com/ocornut/imgui/issues/2117#issuecomment-430732528, 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.
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.
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).
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)
@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 ?
@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).
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,
and after it is positioned in the correct position.
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
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.
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.
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.
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);
As fast feedback:
I'm using up-to-date viewport branch Processor : Intel x86_64 Linuxmint 18.3 using SDL2 + OpenGL 3.0 + glsl 130 (works the same way using OpenGL 3.3 and glsl 150, manualy modified)
After applying your changes + make clean && make, I got one little warning:
./imgui_impl_sdl.cpp:287:24: warning: unused variable ‘viewport’ [-Wunused-variable]
That's imho nothing important, and after that, I tested the sdlgl3_example with the following Window Managers :
- gnome + Compiz compositor
- gnome + Metacity with and without compositor
- gnome + Marco with software compositor, and no compositor
=> I didn't detect any issue.
:+1: congratulations !!
Is there anything else to test ?
I forgot : reversing the changes, the flicker is back, so imho you solved this issue.
Nice :)
Is there anything else to test ?
Could you test the GLFW version? Also hoping for feedback from other users.
This code made sense to allow the same code to work with both Viewport enabled and disabled, but instead I will add an if/else block.
Nice :)
Is there anything else to test ?
Could you test the GLFW version? Also hoping for feedback from other users.
This code made sense to allow the same code to work with both Viewport enabled and disabled, but instead I will add an if/else block.
I just tried 89a530b442d2f989e5ab58e16037c28c990eef9c (viewport branch) on my Retina screen (macOS 10.14.1/GLFW 3.2.1/OpenGL 3). The clipping bug that I reported earlier is still there (with and without the code change that you suggested).
The docking branch on the other hand works great and is already integrated in my current project.
As suggested, I did a kick test using glfw:
Same conditions:
- using up-to-date viewport branch
- Processor : Intel x86_64
- Linuxmint 18.3
- using glfw 3.2 + OpenGL 3.0
After applying your changes + make clean && make, I still see two issues:
- moving an ImGui window outside of the glfw window: Starting point: glfw example + OpenGL3, both hello world and demo window inside the glfw Window.
When I try to move a Dear ImGui window outside of the glfw Window, I have to do it in two moves, because there is sort of ' resistance ' when the ImGui window border reaches and starts to overlap the glfw window border. This makes the mouse cursor no longer dragging the window, and I need to click a second time on the ImGui window to continue dragging it outside. the border. Once done, no other apparent problem occurs (e.g. no more flickering)
- moving an ImGui window from outside, into the glfw window :
Starting point : in the previous try, one ImGui windows was left outside of the glfw Window.
Restarting the glfw example, there is one ImGui window (here the Hello world window) outside of the glfw Window, while the demo is inside.
The issue : I simply can't drag the outside ImGui window, who's stuck to the background. Looks like it cannot be focused anymore.
No problem with the Demo window, who can be focused when put outside, and put back inside after.
Both issues described above occur with or without compositor, using:
- Marco (without compositor, or with software compositor,
- Metacity (without, software compositor, accelerated compositor)
- Compiz (with compositor + hardware acceleration)
Waiting for other to confirm.
Nice progress :) on amd64 + XFCE + glfw3 I no longer notice bugs that I reported:
- segfault when shaking the clear button panel
- the keyboard focus on other applications (like firefox, gedit) when a window is outside the main win
- XFCE docker buttons flickering effects.
Bug still present:
- the outside window is still flickering
- moving the outside window on a new virtual desktop (XFCE) and moving it makes it jumped back to the virtual desktop of the main window.
The SDL version always worked fine for me :)