Project manager window initial position not centered on hiDPI displays

[twoco]

Godot version

v4.0.alpha1.official [31a7ddb]
v3.4.2.stable.official [45eaa2d]

System information

Windows 10

Issue description

See #13017 It's an issue we've had several times before.
I thought it was finally fixed in Godot 4. But I think is slightly another reason. The initial window is centered. But it sizes increases after loading. And btw. the first loading window is just white which is a bad UX. But it seems that this is the same window until the project manager is loaded. In this case the initial centered position does not matter anymore, since the window size changes after loading completed. See recorded screen (gif).

It just feels cheap and annoying when the window behaves like that.

Steps to reproduce

Start Godot. See the initial small window is centered. But the final window state (bigger size) is not centeres.

My screen resolution is: 3840 x 2160 with 200% scale.

This is what I want (window position center):

Update: Same with Godot 3 I see now. I think it's because the window expanse on loaded.

[Calinou]

This is due to the same cause as #13017. I remember it working correctly at some point, but maybe it never did.

Now that projects are DPI-aware by default, some proper way of automatically scaling the window on creation is needed, but it would require the ability to read the OS-provided scale factor instead of detecting our own to work reliably. See godotengine/godot-proposals#2661.

And btw. the first loading window is just white which is a bad UX.

I'm not sure if it's possible to change a window's initial color on Win32 (that is, when not using UWP). Even Electron apps suffer from this to an extent, although their window creation might be a bit faster so it's less noticeable.

[twoco]

Btw. the white color of the initial window is not problem anymore. Just the first start(s) was very slow. Looked like window without response. May be solved by first load the window (less as possible) and set a splash and then load the other stuff. But anyway...

To the issue: The initial position seems to work correctly. The only problem is that the window width and height are changed after loading. Without knowing the code I would guess that either the window position should be centered again or the initial window size should have the same size as the final size. Or create a new window centered, instead of just changing the size. Just some thoughts. But I think you know more about it. :) Just an illustration to compensate for my bad english.

It's a frame from the recorded gif you can see above in the first post. Here you see the window initially size and position is centered. But after that the size is just changed without center it again.

[Calinou]

The white color of the initial window is not problem. Just the first start(s) was very slow. Looked like window without response. May be solved by first load the window (less as possible) and set a splash and then load the other stuff.

This is being tracked in godotengine/godot-proposals#3657.

[twoco]

Ok, I think my guess wasn't quite right. Don't let that confuse you. The final window (red) size is 2x greater then the initial state (green). So I think it's just because the initial state is just not yet scaled to the OS UI scale, right? So back again, it seems to be the initial cause of that problem. I hope we'll find a solution of this. How does other programs handle that?

A workaround could be to start the window maximized. Or move the window half of the new size? If you know the window size you could move it -width/2 and -height/2. But this method is maybe not a solid solution. It should work with all scales. Not only 200%.

In this case my UI scale is 200%.

[Calinou]

Ok, I think my guess wasn't quite right. Don't let that confuse you. The final window (red) size is 2x greater then the initial state (green). So I think it's just because the initial state is just not yet scaled to the OS UI scale, right? So back again, it seems to be the initial cause of that problem. I hope we'll find a solution of this. How does other programs handle that?

Other programs handle this by creating the window at the scaled size automatically, rather than scaling the window via window management functions after it is created.

For the record, this scaling behavior was implemented in #20831. It wasn't designed to be a definitive fix; it's merely a band-aid.

A workaround could be to start the window maximized.

That could work too, but I feel it would be too large when you have 1920×1080 of screen real estate available (if not more).

[TechnicalSoup]

Having taken a brief look at the code i think the window is rezised based on the editor scale setting (with a minimum value of 1). However after the resize the window is not repositioned to the center of the screen. The code to do that is fairly straight forward, and I've got it working in some sandbox testing I'm doing.

I'm happy to put together a PR that will solve the window not being centered, but looking toward a long term solution if we attempt to read the display scaling from the operating system/platform we may hit a hurdle on Windows, as the current compilation parameters look target a minimum build OS of Windows 7 and this may be too low to use some of the more advanced DPI scaling APIs.

[Calinou]

@TechnicalSoup Feel free to open a pull request for this 🙂

I'm happy to put together a PR that will solve the window not being centered, but looking toward a long term solution if we attempt to read the display scaling from the operating system/platform we may hit a hurdle on Windows, as the current compilation parameters look target a minimum build OS of Windows 7 and this may be too low to use some of the more advanced DPI scaling APIs.

Can't we use those APIs conditionally at run-time, similar to enabling ANSI escape codes on Windows 10 and later (for instance)?