Incorrect mouse position likely due to high DPI display

[Sogomn]

InputHandler::mouse_position seems to return incorrect values on displays with high DPI.

The "Screen" size in the image is the window size. Top left of the window is still (0, 0) but the mouse position can be greater than the window bounds without leaving the window.

Occurs on a 3840x2160 28" (~157 DPI) monitor but only recently (since 0.10).

[AnneKitsune]

Thats my bad haha. Normally, screen size should be the physical pixel size. Are you getting this value from ScreenDimensions?

[ghost]

I can actually confirm this as well. My mouse gets higher values than what the ScreenDimensions resource provides.

I assume the problem lies in the resource and not the input.

[Sogomn]

Yeah the window size came from ScreenDimensions.

[AnneKitsune]

I actually tested this and it was working just fine on my hidpi setup when we released.

[azriel91]

Not sure if relevant, but may be.
On my Ubuntu 16.04 laptop that is running Gnome 3.28 on X, the ui example draws a black window for the 0.10 release. That laptop has a 1.3333 hidpi factor. I did try setting it to 1.0 using WINIT_HIDPI_FACTOR=1.0, but it didn't do anything.

[Sogomn]

The screen dimensions are correct for me tho. They are the values I have in my display.ron.

[ghost]

Mine aren't due to Wayland (unless that's the problem). The problem of mine happens in fullscreen so there is no border and i guess the dimesnions should be the same as the screen resolution.

[Sogomn]

Did some more testing on a different device and it here it seems the window size isn't accurate. It's set to 1280x720 in the display.ron but the window fills the entire screen (1920x1080). 96 DPI monitor.
So I think ScreenDimensions returns the correct size the window is supposed to have but the actual window size is wrong?

[AnneKitsune]

We are using the physical size returned by winit instead of converting it to logical size like before. On a 4k monitor with a dpi setting making my resolution 1080p, making the window fullscreen would return the 4k screen size, which was the intended result. Tested on wayland and xorg. We got people that tested it on both windows and mac too. Its possible that when creating the window it is the wrong size, as I might have forgot to update the init code for the window. Is this what you are observing?

[AnneKitsune]

The dpi setting is in ScreenDimensions by the way, if you can check what the value is.

[Sogomn]

Ah, I see. So is there a way to either get the logical mouse position or the physical window size (without multiplying it by the HDPI factor)?

[AnneKitsune]

Normally you should be getting the physical mouse position as well as the physical window size. I'll test on my laptop(hidpi) to make sure the results are valid.

[AnneKitsune]

Okay its clearly broken again for some reason...

[AnneKitsune]

Hello, can you test this and confirm if it works for you? Thanks! #1246

[Sogomn]

Yes, it does!

[yancouto]

Hello!

I think I've been hitting exactly this same issue. When using my large monitor, I see this in the logs:

Guessed window DPI factor: 1.25

And then the mouse position gets "out of sync" with the actual position on the screen by exactly this factor.

So I have a question: is the DPI scaling supposed to be transparent to us users when acessing mouse positions?

• If so, then this is probably a bug that needs fixing.
• If not, then how do I track the current DPI? (In order to take that into account.) I see WindowEvent::HiDpiFactorChanged when reading this, and tried handling that event in my game state, but it does not show up. What is the correct way of tracking DPI?