A vertical offset on ubuntu when a panel is separated from the main window

[shi-yan]

Version/Branch of Dear ImGui:

f1bf642

Version: 1.82 WIP
Branch: docking

Back-end/Renderer/Compiler/OS
Tried both opengl3 and vulkan/ sdl,
gcc-8
ubuntu 18.04 on nvidia / xwindows

Back-ends: imgui_impl_sdl.cpp, vulkan / opengl3
Compiler: gcc-8
Operating System: ubuntu 18.04

My Issue/Question:

I'm testing the docking branch with the official examples. I have tried both the vulkan backend and the opengl3 backend. I have noticed some issues.

One problem is that I noticed a mouse position offset, if the demo window is separated from the main window. The issue is kinda intermittent, because there was one time, after I dragged the main window around, somehow that fixed the offset issue.

It seems that the vertical offset equals the distance between to top boundary and the top border of my screen.

Screenshots/Video

Standalone, minimal, complete and verifiable example:

this is the same official demo, but it has a CMake file

testimgui.zip

[shi-yan]

2021-03-11.13-01-01.mov

I just tried the glfw backend, and the issue is the same.

I think I know how to reproduce it now.

when the demo panel was first detached, I tried to move it by dragging the title bar. But because the imgui window can't be moved outside the screen boundary (see #3899 ), the mouse cursor starts to move away from the title bar. And then, if I release the mouse, I will introduce an offset.

it seems that imgui remembers the hit point when the dragging movement starts, and still uses that point as the mouse location when dragging stops. It doesn't expect relative cursor position would change during dragging.

[shi-yan]

after more tries, I think my previous assessment wasn't accurate.

I think what's happening is that the imgui window's rectangle was actually moved to the outside of the screen. but when rendering, that window is still rendered inside the screen. However when responding to mouse event, the actual rectangle is used. That caused the offset effect.

[rokups]

It is a known issue which we reported to SDL and GLFW and are waiting for fixes.
glfw/glfw#1817
libsdl-org/SDL#3813

[ocornut]

I believe there's two sides to this issue.
Indeed, SDL and GLFW don't support this (maybe X doesn't support it or doesn't recommend it? I don't know)

But the bug on dear imgui side, reported so many times and in so many flavors in #2117 is that we don't properly react to this limitation and expect our platform windows to be at position A (that was requested) when it is in fact at position B. This is the core issue with multi-viewports on Linux which hasn't been solved/fixed since #2117 was started.

[lailoken]

FWIW, the following code keeps SDL and ImGui in sync in this regard.
(For me at least on SDL2 / OpenGL3 backend)

static void SetWindowPos_override(ImGuiViewport* vp, ImVec2 pos)
{
    // call previous callback (on the default one this will simply set the SDL Pos)
    origPlatformIO.Platform_SetWindowPos(vp, pos);

    auto window = ImGui::FindWindowByID(vp->ID);
    if (window)
    {
        // There may also be a discrepancy between where SDL eventually puts the window and where ImGui thinks it is
        // we need to read the position from SDL and update ImGui
        SDL_Window* hwnd = reinterpret_cast<SDL_Window*>(vp->PlatformHandle);
        int x, y;
        SDL_GetWindowPosition(hwnd, &x, &y);
        if (x != (int)vp->Pos.x || y != (int)vp->Pos.y)
        {
            vp->Pos.x = x;
            vp->Pos.y = y;
            vp->WorkPos.x = x;
            vp->WorkPos.y = y;
            window->Pos.x = x;
            window->Pos.y = y;
            // call SDL again to make sure it's correct? seems to need this?
            // the window position will not seem to change, there will be a slight stutter,
            // but the window will be in the correct position according to SDL+ImGui
            origPlatformIO.Platform_SetWindowPos(vp, pos);
        }
    }
}

Hope this helps others.