HiDPI macOS, mouse position is in physical pixels whereas windows creation happens in logical pixels

[golddranks]

I'm using macOS with a HiDPI display, with the scale factor of 2.0.

There is an unfortunate mismatch in the API where the input mouse events are reported in physical pixels (they are scaled according to the scale factor reported by the window), whereas the window creation API naively requests a window of the size of the input values, without specifying the scale factor. A window of those logical pixel dimensions is created, but the physical pixels are double of that.

This leads the user of the library having to scale the mouse values down, or window dimensions up by themselves – and possibly fail to do that, if they are developing with scale factor of 1.0 and don't notice the problem.

Besides, the library documentation speaks mostly of "pixels", but "points" are mentioned too in a few APIs. I guess that the distinction refers to physical and logical pixels, but a explanation of those would be warranted in the documentation itself. (Note: please correct me if I'm wrong! Also, I'd be interested to know how if the distinction was actually considered when writing the docs – do the docs actually reflect some intention of separating those, or was pixel meant to be used as a general term referring both?)

I want to help with the current situation (at least for the macOS implementations), but I'm unaware what plans @tomaka has for the API.

Should a WindowBuilder.with_dimensions(800, 600) create a window of those logical dimensions? In that case, the docs should be changed to refer points, and methods should be added to get the scale factor. Or if with_dimensions was meant to create a window of those physical pixel dimensions, the implementation itself should be fixed, since at the moment it doesn't do that.

I'm going to send PRs once I get input from @tomaka what was the intention.

[kryptan]

I want to help with the current situation (at least for the macOS implementations), but I'm unaware what plans @tomaka has for the API.

Should a WindowBuilder.with_dimensions(800, 600) create a window of those logical dimensions?

You might be interested in discussion in #105. I proposed to use physical pixels everywhere.

methods should be added to get the scale factor.

There are Window::hidpi_factor() and MonitorId::get_hidpi_factor() methods to get scale factor of the window and monitor but the one for monitor is currently not implemented for macOS.

[golddranks]

Thanks for the pointer. It seems that there is a push for being HiDPI aware by default, with #319 merged and all. That means that one should expect the window creation api to create windows based on physical pixels, right?

[kryptan]

Yes, that's the current intention.

[golddranks]

However, because HiDPI-aware windows are meant to adapt to different resolutions when moved to different monitors, the "meant to be" physical pixel dimensions are device-dependent. That means that the window creation API should be reflect that. At the moment it doesn't take in the device the window is going to be drawn on.

[francesca64]

@sodiumjoe window creation on macOS uses physical pixels now, right?

[sodiumjoe]

@francesca64 I believe that's the case as of #435

[francesca64]

@sodiumjoe that looks like it only affects the size methods though? macOS HiDPI is something I can't test, since it doesn't seem to want to cooperate with my 1440p monitor.

[sodiumjoe]

@francesca64 sorry about the late reply. It looks to me like it's still using logical pixels.

The following:

    let _window = winit::WindowBuilder::new()
        .with_title("A fantastic window!")
        .with_dimensions(1440, 900)
        .build(&events_loop)
        .unwrap();

produces a window that fills the screen of my retina 13" macbook pro, which has a native resolution of 2560x1600, but is scaled to 1440x900.

I'm a little confused by logical vs physical, esp. with the default scaling on this machine.

[francesca64]

I'm a little confused by logical vs physical, esp. with the default scaling on this machine.

It's taken me surprisingly long to understand the intentions prescribed in #105, but the gist seems to be that window creation should give you a render surface with that many physical pixels, and that no part of the API should produce or consume logical pixels. This way, handling non-1.0 DPI factors is purely "opt-in".

[francesca64]

Okay I seem to have been wrong about that: #105 (comment)

[francesca64]

I convinced macOS to set one of my monitors to (very low resolution) HiDPI, so I'll be able to take care of this.

[francesca64]

I've confirmed that this issue is still relevant. It will be resolved as part of the API changes that will result from #105.