Rethink the DPI handling for wayland

[elinorbgr]

Got the realization chatting with @chrisduerr about the DPI question that winit could be more proactive in its handling of DPI on Wayland. DPI handling on Wayland has actually two layers we could say:

• the compositor defines a "monitor scale factor", which is an integer. This can be interpreted as the factor by which a non-dpi-aware app will be scaled on this monitor
• if an app announces to the compositor that it uses the same scale factor for drawing, the pixel buffer of the app will be mapped 1-to-1 with the physical pixels it occupies on the screen
• the compositor also signals to the app the physical dimensions of the monitor, and its resolution in use (which winit currently doesn't use).
• using this information, the app can actually compute an exact dpi factor and draw itself perfectly on a buffer whose integer scale factor matches the one of the monitor

Currently, winit does 2 things to handle DPI awareness on Wayland:

• when the integer scale factor of the monitor changes, it resizes the pixel buffer to match the new integer scale factor so that the logical size of the window (physical size divided by integer scale factor) remains constant
• it advertises the integer scale factor as the "dpi scale factor"

This last point is a source of platform friction, as it does not match the meaning of "dpi scale factor" of X11.

A possibility would be to have winit report the scale factor computed from the monitor dimensions (its accuracy would be the same as the ones reported by xrandr on X11), falling back on the integer scale factor if the dimensions are not available or unrealistic. Allowing applications that want to do perfect dpi scaling to use it.

The main issue is that it's really not clear how all this would fit into the "PhysicalSize" / "LogicalSize" framework of winit, as looking at things like that Wayland effectively has two different scale factors.

I don't know what would be the best course of action, but I feel like this is worth discussing. For most apps, considering only the integer scale factor is enough to have a very decent DPI handling, but some apps may not be satisfied by that and may want to access the real DPI of the monitor they are being displayed on, so it may be worth exposing in one way or an other.

PS: as per #972 I don't plan to have any decision taking in that matter, but I feel that this information is worth discussing for the reduction of friction for winit users, so I tried to expose to you all I know about it.

[chrisduerr]

Does any application at all actually do this? I feel like it would be unexpected for users to perform 'better' than just using the default DPI factor configured for the monitor and I'm not sure if this is something the Wayland platform intends applications to do?

[kchibisov]

I agree with @chrisduerr here, if no one is using the approach of getting real dpi, then I think winit shouldn't do this either. The current DPI on Wayland makes sense and I don't think that we should change it.

Oh and it's a duplicate/related of/to #920

[elinorbgr]

Oh right, forgot about this issue. No need for this duplication then.