Skip to content

[rcore][GLFW] Fix window landing off-screen when it's bigger than the monitor workarea - #6015

Open
Gooh456 wants to merge 1 commit into
raysan5:masterfrom
Gooh456:fix-init-window-off-monitor-position
Open

[rcore][GLFW] Fix window landing off-screen when it's bigger than the monitor workarea#6015
Gooh456 wants to merge 1 commit into
raysan5:masterfrom
Gooh456:fix-init-window-off-monitor-position

Conversation

@Gooh456

@Gooh456 Gooh456 commented Jul 24, 2026

Copy link
Copy Markdown

Fixes #6002.

InitPlatform() centers the window with monitorX + (monitorWidth - width)/2. There's no check for the window being wider or taller than the monitor. When it is, that goes negative and the window gets placed outside the virtual desktop. On Windows this isn't just "off-center", glfwSetWindowPos/GetWindowPosition come back with garbage coordinates and the window can stay invisible until you drag it back with win+shift+arrow, which matches what's described in #6002 (portrait primary monitor, landscape window, window vanishes, SetWindowPosition(0,0) right after InitWindow() "fixes" it).

SetWindowMonitor() already handles this correctly, it anchors to the workarea origin instead of centering when the window doesn't fit. This PR just applies the same guard in InitPlatform().

How I checked it: wrote a small repro that calls InitWindow() with a width bigger than my monitor and reads GetWindowPosition() right after.

Before:

RESULT window position: x=2147483392 y=66

After:

RESULT window position: x=0 y=0

Also checked a normal window size still centers the same as before (800x450 on a 1920x1032 workarea gives x=560 y=291, matches the math).

I don't have a real portrait-monitor multi-display setup to reproduce the exact report in #6002, only a single landscape monitor here, so I forced the same code path by requesting a window wider than my monitor instead. Same math, same branch, just couldn't test the literal portrait-monitor case.

…nitor workarea

InitPlatform() centers the window with monitorX + (monitorWidth - width)/2,
with no check for the window being bigger than the monitor. If it is
(landscape window on a portrait primary monitor, or any window wider/taller
than the workarea), that division goes negative and the window gets placed
outside the virtual desktop. On Windows this doesn't just look off-center,
glfwSetWindowPos/GetWindowPos come back with garbage coordinates and the
window can end up invisible until you drag it back with win+shift+arrow.

SetWindowMonitor() already guards against this by anchoring to the workarea
origin when the window doesn't fit, so apply the same check here.

Repro: request InitWindow() with a size wider than the monitor and read
GetWindowPosition() right after. Before the fix this returns a huge bogus
x value instead of a small negative one. After the fix it's anchored to
the monitor origin. Verified on Windows 11 with a single monitor (couldn't
test the original portrait multi-monitor report from raysan5#6002 directly, don't
have that hardware, but the position math is the same code path).

Fixes raysan5#6002

Signed-off-by: Kyue <164024549+Gooh456@users.noreply.github.com>
@raysan5 raysan5 added the windowing Issues about the window system label Jul 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

windowing Issues about the window system

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[rcore][GLFW] Bad window placement with portrait displays

2 participants