On Tue Nov 14 11:21:00 2023 +0000, Alexandros Frantzis wrote:
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?
A proper DPI-aware app should never be scaled, because it should draw at the right DPI for the monitor. It seemed to me that this wasn't true with your MR, but maybe I misunderstood how this works on the Wayland side.