"Window Placement Centered" causes game window to appear offscreen on hi-DPI laptop

[zejji]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Operating system or device, Godot version, GPU Model and driver (if graphics related):

OS: Windows 10
Device: Dell XPS 15 9560
GPU: Nvidia GTX 1050
GPU Driver: 388.00
Screen Resolution: 3840 x 2160 px
Godot version: 3.0 alpha 2

Issue description:

• Actual behaviour:

If Window Placement - Centred is selected in Editor Settings, when running a project using the 'Play Project' button, the game window opens outside the visible screen area (to the bottom-right). I have to move the window back onscreen to see it.

(However, Window Placement - Top Left works fine.)

• Expected behaviour:

The game window should be centred if Window Placement - Centred is selected in Editor Settings.

Steps to reproduce:

Load any project which runs windowed and ensure that Window Placement - Centred is selected in Editor Settings. Press 'Play Project'.

Link to minimal example project:

Bugsquad edit: Keywords for searching: Windows, window, placement, location, position, screen, scaling, incorrect, offscreen, bottom, right, corner, bottom-right, center, centered, 125%, 150%, 175%, 200%, expected, unexpected, resolution.

[Calinou]

Does this happen if you mark the editor executable as DPI-aware, by right-clicking its .exe file, going to Properties → Compatibility then overriding the scaling mode to Application?

If the window is set to be DPI-aware, this should be fixable by getting the DPI from the engine (which is already possible), then placing and sizing the window accordingly.

[zejji]

@Calinou - many thanks for the quick response.

I can confirm that overriding the scaling mode to 'Application' does solve the issue, i.e. the window which appears on pressing 'Play Project' is now centred.

One minor side effect which I noticed is that, after switching to 'Application' scaling mode, the Project Manager window which loads on startup is now a bit too small by default (a screenshot is attached).

[Calinou]

One minor side effect which I noticed is that, after switching to 'Application' scaling mode, the Project Manager window which loads on startup is now a bit too small by default (a screenshot is attached).

I have already reported that, so I'm adding the "confirmed" label to that issue.

[willvincent]

This is not limited to windows. I see the same on my mid 2014 macbook pro with retina display. Running Godot 3.0 beta 1

UPDATE

I launched manually from the terminal and when executing my test scene I see the --position specified. After a bit of playing around, it looks like those values divided by 3 are pretty accurate centered placement.

Values I see are: --placement 1408,900 if I manually use 470,300 in the window placement settings within editor settings I get a window roughly where I expect to see it.

[richardeigenmann]

Motivated by the presentations at FOSDEM 2018 I downloaded Godot 3.0-stable on my Win 10 Lenovo Yoga 3 Pro hidpi laptop and started the getting started tutorial. It was most confusing to not find the play window despite repeated play button pushes. Only after some head-scratching and right-clicking on the taskbar icons did it become apparent that the window is somewhere far off to the bottom right of the desktop and needs to be dragged up with "Move" or "Maximise". This is not a good experience to the newbie trying to get started.

[AttackButton]

I confirm this issue. In a 1920x1080 screen I need to put custom position like (420, 130) to the run screen be "centered".

[jaran]

I have this issue on mac. took me forever to finally see a small sliver of the window bottom right.

[willvincent]

I no longer have this issue on 3.0.2

[Nachasic]

OS X 10.13.4
MacBook Pro with Retina with external FullHD monitor (which Godot is running on), same issue

[ghost]

Same problem here. :/

[ffxsam]

Still having this problem in the latest version of Godot (3.0.2). macOS 10.13.4.

Though if I go to Project Settings > Display > Window and enable "Allow Hidpi", this fixes it.

[KoBeWi]

I guess that would fix it: #23203

[ReneHabermann]

Can reproduce at 3440x1440 resolution. Apparently it's not related to the windows UI scaling, same offset for 100% scaling and 150% scaling.

[rolbr]

Same problem here. Setting Allow HiDPI in the project settings kinda fixes this issue and correctly centers the game window, but then it'll be super tiny and you need to also set Test Width and Test Height to something more manageable.

Leaving Allow HiDPI disabled but then set Editor Settings > Run > Window Placement > Rect to Custom Position and giving the rect a position of 248,100 also centers the game window correctly — but only for that very project resolution.

System:

• Win 10 on a Dell XPS 9555
• 3840×2160
• window scaling 250% (default)

Project Settings:

• 1024 × 600
• HiDPI disabled

Editor Settings:

• Window Placement custom rect at 248, 100

Result:

	margin left	game window width	margin right	total
Device PX	640	2560	640	3840
divided by 2.5	256	1024	256	1536

The first row are the pixel values measured from a screenshot when running the game (I only measured the X axis, but I'm pretty sure vertically it's the same)
The second row then is all the values from the top row divided by 2.5 as per the 250% window scaling.

Soooo... the measured window width of 2560 perfectly translates to the project setting of 1024, I guess the Editor Setting Window Placement somewhere mixes up the scaling between game pixels and device pixels.

[HubKing]

I was about to open a new issue for this, but since it already exists... I am experiencing the same problem.

Godot Version: 3.2.1.stable.mono.official
OS: Windows 10 (2004)
Monitor: 4K, 200% DPI.

When the position is set to "Centred", it shows only the second quadrant of the game window at the bottom-right corner of the monitor.

[Calinou]

@HubKing Try enabling Display > Window > Allow Hidpi in the Project Settings. (For the record, this isn't done by default because your game must be configured to support multiple resolutions. Also, this may perform poorly on integrated graphics.)

[HubKing]

@Calinou That did make the game window appear at the centre. Thank you for the information. It may be helpful to show some kind of information message box like "Warning: high DPI option has not been enabled" (with "Do not show again" option, of course) when the user clicks the "Play" button for the first time and the system uses high DPI, so that the user would not think it as a bug of the editor.

[KoBeWi]

so that the user would not think it as a bug of the editor.

This IS a bug of the editor though and an annoying one, especially when you run lots of different projects and you have to set this option for each of them.

[KoBeWi]

Reopening, because it wasn't fixed (the PR was for Mac OS, while this is also Windows issue, maybe that's why).
Tested in 8ccb1ce

[Calinou]

Why can't the game window be centered with Allow HiDPI on or off on both high and low DPI situations? Why does DPI even matter in this case?

Unfortunately, multi-monitor and displays with different DPI make this more difficult than expected. There's a lot of code that needs to be changed to ensure setting the window position/size works the same regardless of the Allow Hidpi project setting. Also, the windowing system has changed in the master branch, so fixes would have to be made there instead of in the 3.x branch at first.

Fair, but what's the point of Test Width if it's being included in the exported build? The word Test sort of implies it's only for testing -- as if it won't be included in the export.

See #36390.

[twoco]

A workround is to set the compatibility DPI mode on windows for the application to e.g. "System". So it handles like no UI scale applied on system. In my case I have a 200% scale. But the compatibility fix should not the solution for this issue.

This issue is about the game itself which can be fixed by the project setting "Allow HiDPI" in window (display) and the most games goes fullscreen. ... I have more a problem with the project manager window which appears on Godot start and described in #42214.

What do you think. Can we fix this soon? I could, but not experienced enough to this code. But can help with some ideas. Can we just use the same implementation as the "Allow HiDPI" for this launcher window? Or just rewrite the part of position initialization. How do other applications do that? Or just add a new parameter in a config file for the ui scale. Like 2 for 200% and compute it for the center position.

[Calinou]

To work around the project manager's positioning issue, you can specify the window position and size explicitly using the --position X,Y and --resolution WxH command line arguments (or use --maximized). You can specify command line arguments by creating a shortcut to the Godot executable, then right-clicking this shortcut and choosing Properties.

What do you think. Can we fix this soon? I could, but not experienced enough to this code. But can help with some ideas. Can we just use the same implementation as the "Allow HiDPI" for this launcher window?

Allow Hidpi is always enabled for the editor and project manager unless you pass the --low-dpi command line argument.

Or just add a new parameter in a config file for the ui scale. Like 2 for 200% and compute it for the center position.

This is already available in the Editor Settings (Interface > Editor > Display Scale).

[twoco]

Ok thanks. C:\...\Godot.exe resolution WxH works in a Windows shortcut. Good to know. 👍

Allow Hidpi is always enabled for the editor and project manager unless you pass the --low-dpi command line argument.

It's only about the project manager who isn't working (position only, scale works). But resolution WxH works. In my case this is what I wanted. The project manager is not centered and the editor and game works like before. I just had to enable "Allow HiDPI" for my game. And for me I also set the Test Width / Height to have an internal resolution what modern engines has. ... Anyway, we could set this parameter by default. But what exactly does this mean (WxH)? Any docs?

[Calinou]

It's only about the project manager who isn't working (position only, scale works).

This is because the project manager code only sets the window size, not the position:

godot/editor/project_manager.cpp

Lines 2413 to 2414 in 1ceba6e

	// TODO: Resize windows on hiDPI displays on Windows and Linux and remove the line below
	OS::get_singleton()->set_window_size(OS::get_singleton()->get_window_size() * MAX(1, EDSCALE));

I'll look into it but I can't promise I'll manage to fix it.

But what exactly does this mean (WxH)? Any docs?

It's width x height in pixels; see Command line tutorial or run the Godot executable with --help.

[twoco]

The funny thing is that when I run Godot with just C:\...\Godot.exe resolution (only the word resolution nothing else), the window has the same size as before but is centered. I've created a WIndows Lnk file and just added resolution behind the exe of the target path with no values (WxH). And the result is exactly what I wanted.

[Calinou]

The funny thing is that when I run Godot with just C:\...\Godot.exe resolution (only the word resolution nothing else), the window has the same size as before but is centered. I've created a WIndows Lnk file and just added resolution behind the exe of the target path.

resolution is not a valid command-line argument, but --resolution is. (Godot doesn't print an error on invalid command line arguments as the project may interpret those.)

[twoco]

Hehe you're right. C:\...\Godot.exe banana also works. But why? 😆
So just adding a random word as argument will fix this issue here. The window is centered without any other change (e.g. size).
I'm happy with that. But this is weird. And should be implemented correctly.
I guess that Godot just stops executing some position related code when passing a not expected argument. I see no errors. Maybe an intern error or if-condition.

[twoco]

Ok wait. When I launch Godot with such argument it logs to the root path of its exe ./logs/godot.log:

Godot Engine v3.3.3.stable.official.b973f997f - https://godotengine.org
OpenGL ES 3.0 Renderer: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
OpenGL ES Batching: ON
 
**ERROR**: Condition "default_certs != __null" is true.
   At: modules/mbedtls/crypto_mbedtls.cpp:201:load_default_certificates() - Condition "default_certs != __null" is true.

But no further problems. But why is the window centered in this case? And all other stuff works like expected. The window size is ok like default (without args). The only effect I get with this error is that the window is centered and this issue fixed. ^^ So maybe there is code which is not exectued causing to the error above. I guess there is some code of window position which can just be removed to work. idk.

[Calinou]

See #38202 (comment). It's likely a race condition. Chery-picking #49661 to 3.x would likely resolve it (which will reintroduce this issue when you pass invalid CLI arguments here).

[twoco]

But does that mean there is code for the window position that won't execute when this error is caused? In other words: We can just remove the section of window position code to fix this issue? Or what do you think? Why is the window centered in this case?

Not this line:

godot/editor/project_manager.cpp

Lines 2413 to 2414 in 1ceba6e

	// TODO: Resize windows on hiDPI displays on Windows and Linux and remove the line below
	OS::get_singleton()->set_window_size(OS::get_singleton()->get_window_size() * MAX(1, EDSCALE));

Because the widnow size is exactly the same as without the error / invalid argument. It's really only the position which is now fixed / centered. Or do you think this is the right line? But the window size does not differ between both states. 🤔

So just removing it will fix this? (Maybe not for all users?)

[Calinou]

So just removing it will fix this? (Maybe not for all users?)

Removing that line will cause the window to be too small on hiDPI displays, since it won't be resized to match the editor scale. This line was originally added in #20831 as a hack. The ideal way to solve this problem would be to scale created on Windows and Linux as is done on macOS, but it's not trivial to implement.

[cybereality]

So I encountered this problem as well on Windows 11 and a 4K monitor. I was able to hard code a window position in the editor settings, so that is an okay work around for now, but I think we should look into fixing it. I put together some code that appears to work fine on Windows 11 (and the APIs should be supported as far back as Windows 2000). Not sure if you tried this before, but it seems to work on my machine. Maybe that will help.

#include <iostream>
#include "Windows.h"

int main() {
    std::cout << "== Monitor Scaling ==" << std::endl;
    HMONITOR monitor = MonitorFromWindow(GetActiveWindow(), MONITOR_DEFAULTTONEAREST);
    MONITORINFOEX info;
    info.cbSize = sizeof(info);
    GetMonitorInfo(monitor, &info);
    int logical = (info.rcMonitor.right - info.rcMonitor.left);
    std::cout << "Logical = " << logical << std::endl;
    DEVMODE mode;
    mode.dmSize = sizeof(mode);
    mode.dmDriverExtra = 0;
    EnumDisplaySettings(info.szDevice, ENUM_CURRENT_SETTINGS, &mode);
    int physical = mode.dmPelsWidth;
    std::cout << "Physical = " << physical << std::endl;
    double scale = ((double)physical / (double)logical);
    scale = round(scale / 0.25) * 0.25;
    std::cout << "Scale = " << scale << std::endl;
}

I can look into Linux later, but I'm going to assume it may be harder than Windows.

[cybereality]

So I spent the day trying to detect display scaling in Linux (Ubuntu Wayland and X11). It doesn't look like an easy thing. I was able to get some resolution values from the Xlib library, but they don't seem to make any sense. I tried everything I could think of, but it just wasn't working. I'll revisit this later because there has to be some way, maybe I'm missing something. I don't know.

[cybereality]

Actually, I was able to get it working with Xlib. At least on Ubuntu X11 GNOME. I can detect the proper screen scaling now. However, it doesn't seem to work under XWayland and I scoured the whole API. I also think that different desktop environments handle scaling differently, so I'm not sure it's portable to other distros. But it's a start and I will keep looking into it.

[sabbir360]

Same problem here. Setting Allow HiDPI in the project settings kinda fixes this issue and correctly centers the game window, but then it'll be super tiny and you need to also set Test Width and Test Height to something more manageable.

Leaving Allow HiDPI disabled but then set Editor Settings > Run > Window Placement > Rect to Custom Position and giving the rect a position of 248,100 also centers the game window correctly — but only for that very project resolution.

System:

• Win 10 on a Dell XPS 9555
• 3840×2160
• window scaling 250% (default)

Project Settings:

• 1024 × 600
• HiDPI disabled

Editor Settings:

• Window Placement custom rect at 248, 100

Result:

margin left game window width margin right total
Device PX 640 2560 640 3840
divided by 2.5 256 1024 256 1536
The first row are the pixel values measured from a screenshot when running the game (I only measured the X axis, but I'm pretty sure vertically it's the same) The second row then is all the values from the top row divided by 2.5 as per the 250% window scaling.

Soooo... the measured window width of 2560 perfectly translates to the project setting of 1024, I guess the Editor Setting Window Placement somewhere mixes up the scaling between game pixels and device pixels.

It's working for 4k display with scaling at 250%