Linux/Mac compatibility of multi-viewports #2117
Comments
ocornut
changed the title
|
The discussions involving @Ylannl @ebachard, @s-ol, @Lecrapouille starts around here: |
|
👍 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:
|
|
@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: Then I added some asserts: 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 It is calling the handler when There is maybe a possibility this gets called during the frame after window destruction. |
|
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 Also I added printf in: And finally inside For me the NULL pointer comes from this code: With valgrind + printf I see that: After some iterations we reach the assert: |
|
@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: then several cycles after: 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 |
|
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 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: To reproduce the crash :
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.
Expected : should open the colorpicker
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): You have to add in Makefile the file I've truncated the bug report (after the crash) but there the stack calls (which rephrases what we wrote): |
|
The following message is to report the macOS compatibility of the viewport branch using the
|
|
@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 #1542 (comment)
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 #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 |
|
You should try this.
|
|
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: |
|
@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:
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 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 OS: Fedora 28 About the ColorEdit box problem, I noticed that when shows the coloredit popup, appear a new "Untitled Window" on task bar. OS: Fedora 28 The ImGuiConfigFlags_ViewportsNoTaskBarIcon flag: on linux do not works OS: Fedora 28 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 Strange rebound between main viewport and desktop when I reach the border of screen (desktop) with the window (also in Fedora). OS: Wine 3.14 under Fedora 28 I tested Win64 executables on wine 3.14, under Fedora 28, with OpenGL 4.5. OS: OS X 10.14 (Mojave) The app is functional: no crash. OS: Windows 10. The app is almost perfect: I used it for a long time an works fine, no crashes, no errors!
and after it is positioned in the correct position.
It does it again if I move the mouse and reposition it. That's all. 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. because Calls stak (This happens occasionally, almost infrequently, not in every call) If I use: the application does not crash anymore, nor with the ColorEdit popup, nor with any other popup. |
|
Little update: Using up-to-date viewport branch 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:
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 Change to And for GLFW in imgui_impl_glfw.cpp you may try to change to |
|
Any chance the @rokups workaround (at least for GLFW) be applied soon, until GLFW guys fixes it? If not perfect (I also have the offset issue, also unresponding viewports when initially detached), it is at least much more usable |
|
I have been playing around a bit with this the last days and ran into a small issue on my setup. I use Ubuntu with i3. So what happens is when I drag the window outside of the main window The issue is in this code https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_glfw.cpp#L558-L561 There is a comment about why it's there, but if I remove the check for me it works as it should (i.e the system will be notified about the new size and the correct framebuffer size will be used) I'm not sure exactly what the fix is here, but locally I will have this check removed so I just wanted to let people know about it (also sorry if this has been posted before :) |
|
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? |
|
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. |
|
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" |
We still can not drag a window outside of screen rect using |
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. |
|
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: 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. |
|
Hi, I'm getting some issues with the docking branch on Ubuntu X11. Version: 1.87 Back-ends: OpenGL |
|
Hi, I have some issues on MacOS with Vulkan backend. Screen.Recording.2022-05-05.at.17.21.54.mov |
|
If enable 'No background' checkbox in demo window, this issue appears too Screen.Recording.2022-05-05.at.17.38.53.mov
|
|
The multi-viewport feature is somehow causing my X server to crash. Environment:
Steps:
On step 4 the whole X server crashes. In the X server log file I can find the following stack trace: 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. |
|
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:
Software:
GLFW + OpenGL3 demo: demo.webmUnfortunately, 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 |
|
Window shakes when moving m3.webm
|
|
I guess this could be helpful if implemented in GLFW: |
|
i dont know how to do this on mac can someone help |
|
@
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.webmTo summarize: 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:
|
|
Thanks for offering to help. I have recently purchased a Mac and looking into issue has been one of the reason for it. I confirmed I have similar issues on Mac due to the reason you mention and that means there’s homework I can now chew on (slowed down by the fact that using a Mac is slightly foreign land to me, so it takes a bit of courage to me to even touch it).
I could look into fixing it myself. But I'll need some support.
Over time I have worked on better regression testing for viewports, and as imgui_test_suite / imgui_test_engine (https://github.com/ocornut/imgui_test_engine) now includes a null backend “mocking” backend viewports support with a simple emulation layer. The general idea onwards is that we will improve this emulation layer to simulate exactly that sorts of things, and hopefully that will lead is to a path of sanity.
If you are curious about it try running the test suite with -viewport option, and see the null backend viewport emulation code in shared/imgui_app.cpp.
When I’ve made progress for Mac I’ll probably be asking Linux-etc users to validate some of the improvements.
|
|
Hi, I did some experimenting and have some things to share:
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. |
and others
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 text was updated successfully, but these errors were encountered: