Secondary viewports clamped to monitor boundary during drag; content shift when OS refuses position (Linux/X11)

[geonheekim]

Version/Branch of Dear ImGui:

Version 1.92.8 WIP, Branch: docking

Back-ends:

imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp

Compiler, OS:

Linux Ubuntu 22.04, GCC 11.4.0, X11/GNOME Shell, kernel 6.8.0

Full config/build information:

ImGuiConfigFlags_NavEnableKeyboard | ImGuiConfigFlags_DockingEnable | ImGuiConfigFlags_ViewportsEnable

Details:

My Issue / Question:

When a window is undocked into a secondary viewport (a separate OS window), it
cannot be dragged beyond the monitor edge — it hits an invisible wall — even
though the main GLFW window and other native apps (e.g. VSCode) can freely cross
that boundary.

Additionally, while the secondary viewport is at or near the monitor edge, the
rendered content (e.g. a crosshair drawn at mouse coordinates) appears visually
offset from the actual cursor position.

---

Root cause (traced in source):

1. Monitor-edge wall — ClampWindowPos in imgui.cpp (around the
   window->ViewportOwned branch, ~line 8257–8272) limits the window position to
   monitor->WorkPos + monitor->WorkSize expanded by -visibility_padding
   (default DisplayWindowPadding = {19, 19}). The PlatformMonitorsFullWorkRect
   path that allows straddling (#7299, #3071) is only entered when
   g.MovingWindow != NULL && window->RootWindowDockTree == g.MovingWindow->RootWindowDockTree.
   During a viewport-owned drag this condition is met, but visibility_rect is
   then expanded by -visibility_padding which still applies 19 px of clamping —
   the window can get close to the edge but not past it.

2. Content shift — NewFrame() sets viewport->Pos to the desired position
   (cursor − grab delta, which may be beyond the monitor edge).
   TranslateWindowsInViewport has already shifted imgui child windows to
   LastPlatformPos (the actual OS position, clamped by the WM).
   So after NewFrame():

   • ImGui child-window global coordinates are based on P_actual
   • viewport->Pos (== DisplayPos) equals P_desired
   • Result: every pixel in the viewport is rendered with a
     P_actual − P_desired offset → crosshair and mouse-position overlays
     appear shifted by the "overshoot" amount.

---

Expected behavior:

Secondary viewports should be draggable beyond the monitor edge the same way the
main window is (the OS/WM ultimately controls whether the window actually moves).
Rendered content should never appear shifted relative to the cursor while dragging
near a monitor boundary.

---

Steps to reproduce:

1. Enable ImGuiConfigFlags_ViewportsEnable.
2. Undock any window so it becomes a secondary OS window.
3. Drag the secondary window toward and past the monitor edge.
   → Window stops at ~19 px from the edge (the DisplayWindowPadding limit).
4. While it is stopped at the edge, content rendered at io.MousePos (e.g. a
   crosshair) appears shifted by the amount the drag "wanted" to move the window
   further.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

// Standard docking+viewports example (Dear ImGui demo is sufficient to reproduce).
// 1. Run imgui_demo with viewports enabled on Linux/X11.
// 2. Undock "Dear ImGui Demo" window (drag it out of the main window).
// 3. Draw a crosshair at io.MousePos inside the secondary window's Begin/End.
// 4. Drag the secondary window to a monitor edge.
// Observe: window stops moving before the edge; crosshair shifts from cursor.

ImGui::SetNextWindowPos(ImVec2(0, 0), ImGuiCond_Once);
ImGui::Begin("Viewport test");
ImVec2 p = ImGui::GetMousePos();
ImGui::GetForegroundDrawList()->AddLine({p.x - 10, p.y}, {p.x + 10, p.y},
IM_COL32(255, 0, 0, 255));
ImGui::GetForegroundDrawList()->AddLine({p.x, p.y - 10}, {p.x, p.y + 10},
IM_COL32(255, 0, 0, 255));
ImGui::End();

[ocornut]

Can you open Metrics/Debugger and report the contents of Viewports>Monitors ?

[geonheekim]

Here is the Metrics/Debugger → Viewports → Monitors output:

Monitor 0: MainPos=(5040,0) MainSize=(1920,1080) WorkPos=(5040,27) WorkSize=(1920,1053) DpiScale=1.00
Monitor 1: MainPos=(0,0) MainSize=(3840,2160) WorkPos=(0,27) WorkSize=(3840,2133) DpiScale=1.00
Monitor 2: MainPos=(3840,0) MainSize=(1200,1920) WorkPos=(3840,27) WorkSize=(1200,1893) DpiScale=1.00

3-monitor setup on Linux/X11, GNOME Shell:

• Monitor 1 (4K, 3840×2160) — left, primary
• Monitor 2 (portrait, 1200×1920) — center
• Monitor 0 (1080p, 1920×1080) — right

The artplot main window runs on Monitor 0 (right).
The secondary viewport (undocked panel window) hits the invisible wall
when dragged toward any monitor edge, while the main GLFW window
and other native apps (e.g. VSCode) can cross freely.

[geonheekim]

On debug, the screen drags and moves out of the monitor, but in reality it is impossible to move out of the monitor.

[geonheekim]

I ran into the same content-offset issue on GNOME/X11 (GLFW + OpenGL3 backend) and resolved it using the delta-accumulation approach discussed in #8330 (credit to @hultsi).

The fix I applied to imgui.cpp in UpdateMouseMovingWindowNewFrame():

#ifdef __linux__
    static ImVec2 s_drag_pos;
    static bool s_dragging = false;
#endif
    if (g.IO.MouseDown[0] && IsMousePosValid(&g.IO.MousePos) && !window_disappeared) {
#ifdef __linux__
        if (!s_dragging) {
            s_drag_pos = g.IO.MousePos - g.ActiveIdClickOffset;
            s_dragging = true;
        } else {
            s_drag_pos += g.IO.MouseDelta;
        }
        // Clamp to combined desktop bounds (multi-monitor aware)
        ImVec2 desktop_min(FLT_MAX, FLT_MAX), desktop_max(-FLT_MAX, -FLT_MAX);
        for (int i = 0; i < g.PlatformIO.Monitors.Size; ++i) {
            const ImGuiPlatformMonitor& mon = g.PlatformIO.Monitors[i];
            desktop_min = ImMin(desktop_min, mon.WorkPos);
            ImVec2 end = mon.WorkPos + mon.WorkSize;
            desktop_max = ImMax(desktop_max, end);
        }
        s_drag_pos.x = ImClamp(s_drag_pos.x, desktop_min.x, desktop_max.x - moving_window->Rect().GetWidth());
        s_drag_pos.y = ImClamp(s_drag_pos.y, desktop_min.y, desktop_max.y - moving_window->Rect().GetHeight());
        ImVec2 pos = s_drag_pos;
#else
        ImVec2 pos = g.IO.MousePos - g.ActiveIdClickOffset;
#endif

This eliminates the content offset / crosshair misalignment completely. The clamping keeps s_drag_pos in sync with what GNOME Mutter will actually allow, so ImGui never fights the WM.

One remaining question: is there any supported way to allow secondary viewports to move outside monitor bounds? The main application window can be dragged off-screen by the user (the WM allows it for user-initiated drags), but glfwSetWindowPos() calls are always clamped by GNOME Mutter regardless of _NET_WM_WINDOW_TYPE. Setting override_redirect = True bypasses WM clamping but removes the window from the taskbar and Alt+Tab entirely. Is there a cleaner approach planned?

[ocornut]

This eliminates the content offset / crosshair misalignment completely. The clamping keeps s_drag_pos in sync with what GNOME Mutter will actually allow, so ImGui never fights the WM.

Thanks for the suggestion.
I should aim to starting emulating quirks like like in the viewport "emulator" used by the test engine (https://github.com/ocornut/imgui_test_engine/blob/main/shared/imgui_app.cpp#L1439) so we have some hope of maintaining stuff like this better (otherwise I cannot repro). It would be good that I also develop a plugin that hijack viewport support in an existing backend (e.g. win32) to simulate those constraints.

Do you have some reasonable suggestion that how I can emulate the behavior of your WM ?

[geonheekim]

The most impactful behavior to emulate is the async clamped position:

Platform_SetWindowPos + Platform_GetWindowPos (one-frame lag)

Mutter clamps the window so the titlebar stays accessible, then reports
the clamped position via ConfigureNotify asynchronously. So GetWindowPos
returns the clamped value, not what SetWindowPos was called with.

Minimal emulation:

static ImVec2 s_actual_pos = requested;

// Platform_SetWindowPos:
pos.y = ImMax(pos.y, monitor.WorkPos.y);  // titlebar can't leave top
pos.x = ImClamp(pos.x, -(size.x - 100.f),
                monitor.WorkPos.x + monitor.WorkSize.x - 100.f);
s_actual_pos = pos;  // store clamped, return it next frame

// Platform_GetWindowPos:
return s_actual_pos;  // clamped, NOT the desired value

This alone creates the viewport->Pos (desired) != LastPlatformPos (actual)
mismatch that triggers the content-shift and the ClampWindowPos wall.

Y is stricter than X
Mutter keeps top ~30px of the window within WorkArea on Y. On X, windows
can travel several hundred pixels off-screen. So the emulated clamp should
be asymmetric (Y hard-clamped to WorkPos.y, X soft-clamped with ~100px margin).

Two ConfigureNotify events (harder to emulate)
XMoveWindow generates two events: one immediate (desired), one after Mutter
compositing (clamped). If IgnoreWindowPosEventFrame only covers the first,
the second fires as a spurious PlatformRequestMove mid-drag. Emulate by
returning desired from GetWindowPos on frame N, then clamped on frame N+1.