On Fri Nov 10 09:46:41 2023 +0000, Alexandre Julliard wrote:
This is not correct for DPI-aware apps. It should be something like `window_dpi / system_dpi` (or better, `window_dpi / monitor_dpi`, but we don't quite support per-monitor DPI yet).
Under Wayland the compositor is responsible for applying the monitor scale, so we don't need to factor it in our client side calculation. We just need to communicate the normalized dpi (`scale` in Wayland parlance) at which the contents are rendered. This is done implicitly by setting the surface-local size (e.g., through `wp_viewport`) accordingly. The compositor then uses this information and the scale factor of the output the surface is on, to present the contents at the proper physical size (and thus autoscale on dpi mismatches).
Here is a table describing how this works (also see images in description):
| window size | window_dpi | surf_scale (= window_dpi / 96.0) | surface-local size (= window_size / surf_scale) | compositor physical (= surf_size _* monitor_scale = window_size_ * monitor_scale / surf_scale), monitor scale 1x | compositor physical, monitor scale 2x | |-------------|------------|----------------------------------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|---------------------------------------| | 512 | 96 | 1 | 512 | 512 | 1024 | | 512 | 192 | 2 | 256 | 256 | 512 |
I have added a comment to the `scale` field, but perhaps also using a different name, e.g., `normalized_dpi` or `surface_scale` (open to suggestions), would help with clarity?
Do you think we want a different scaling behavior from what's implemented in this MR?