Correct handling of DPI related information

[edwin0cheng]

Continue discussion from #3

[edwin0cheng]

@IvoWingelaar, @jice-nospam Indeed, I would prefer to discuss all these changes in issue page first and make it easy to track.

On the other hand, Here is my two cents about DPI related issues:

Mouse coordinates and Window sizes should be returned and stored as Logical* values. These are DPI, and DPI-change insensitive.
If using for example glViewport, you simply multiply these values with a hidpi factor.

I think it is okay in general, but how to handle multiple-monitor situation ? Of course currently unrust did not handle it, but for Native values we do not require to handle it (except UI).

Or, How about we embed the DPI information in all these Logical values (e.g. a tuple / struct (x,y, w,h,dpi), or an enum which provide the information and conversion ) ?

When drawing things that need to be pixel-perfect, either disable the DPI flag I proposed, or divide the coordinates/locations by the hidpi factor.

This one is a little bit tricky. I would recommend us to provide a logical to native conversion utility, or as above mentioned, use an Enum to represent all DPI related information.

[IvoWingelaar]

think it is okay in general, but how to handle multiple-monitor situation ?

I'm not quite sure what you mean with this, but if we drag a window from one screen (with DPI 1.0 for example) to another screen (with DPI 1.5), these values do not change. That's the entire reason why we want to use the glutin::dpi::Logical* values. The only thing that needs to happen to correctly handle this in the draw loop is to use glViewport with glutin::dpi::PhysicalSize.

Or, How about we embed the DPI information in all these Logical values

Is copying the two glutin structs not an option? We can't reexport them from glutin because we don't compile that crate on wasm platforms (can you reexport a single module from a crate?). But they have a sensible design and all necessary conversion functions. We might even place a link in the uni-app docs to the explanation in the glutin::dpi module.

This one is a little bit tricky.

All solutions we can implement are going to be hacks. Intercepting a DPI-change event and force resizing the window to the correct resolution will "flicker" the size for a single frame. It might actually be better to convince the winit contributors of this use-case and ask them to implement a force_dpi flag on their end.

[IvoWingelaar]

It appears a similar discussion is already happening here. We should probably just wait for this to settle.

[edwin0cheng]

It appears a similar discussion is already happening here. We should probably just wait for this to settle.

Indeed, It is a great read. let's wait and see if it is settled.
On the other hand, I feel sorry as I am still feel confused about this issue, because it is related to too many stuffs, i.e, multiple screen, multiple platform (inconsistent behavior) etc.

And i don't have a use-case either (i don't have a high-dpi monitor for windows testing), so if you have any idea, please let me know.

[icefoxen]

I'm not quite sure what you mean with this, but if we drag a window from one screen (with DPI 1.0 for example) to another screen (with DPI 1.5), these values do not change.

Just peeking in, apparently winit should produce a HiDpiFactorChanged event in that case. What it does when a window overlaps two screens is something I haven't investigated, I admit, but that's a quite literal edge case...

[edwin0cheng]

@icefoxen Thanks. And just want to ask a related question, what is the plan of ggez to handle something like force_dpi flag feature (People want to use PhysicalSize instead of LogicalSize) ? I can see some games (e.g roguelike games) with need pixel perfect information.

[IvoWingelaar]

@icefoxen I assume it does nothing until you're fully inside the new monitor. You need exactly one physical size for glViewport to work correctly, for example.

It's a shame that I currently do not have a setup with which I can check this ☹️.

[icefoxen]

@edwin0cheng ggez's DPI discussion is happening here, it's nooooot 100% settled yet how it will work out. I intend to have a force_dpi feature of some kind but not sure yet whether we can make it work easily and acceptably in winit, or whether it will need to be implemented in ggez.