Wayland windows created with PhysicalSize have an incorrect size

[QuantumBadger]

A user of Speedy2D has reported an issue (QuantumBadger/Speedy2D#60) where windows are created with a different size on Wayland compared to X. It looks like the root cause might be in the winit library (or at least, a quirk of Wayland which winit isn't handling).

It can be reproduced as follows:

• Start a Wayland session with weston --scale=2
• Inside the Wayland session, run the Speedy2D hello_world example, which creates a window using PhysicalSize(640, 240):
  • cargo run --example=hello_world

Expected behaviour (works correctly on X): A window is created with dimensions 640x240.

Actual behaviour (on Wayland): A window is created with double the size, 1280x480.

It looks like the root cause is that scale_factor is being detected as 1 here:

winit/src/platform_impl/linux/wayland/window/mod.rs

Line 92 in ce890c3

let scale_factor = sctk::get_surface_scale_factor(&surface);

size.to_logical::<f64>(scale_factor as f64) on line 102 therefore has no effect, and so 640x240 is provided to the system as the logical size of the window, when this should actually be 320x120.

[kchibisov]

It looks like the root cause is that scale_factor is being detected as 1 here:

Yes, initial scaled factor on Wayland is 1. There's no way around it to make it 2 or some other value, unless Wayland protocol got updated.

From the logical point of view keeping physical size constant doesn't make any sense, since that's what logical scale is for. Maybe we should disallow physical size for Wayland at all...

[kchibisov]

But in general, don't use scale factor of some monitor on Wayland as a scale factor. Just always use 1 before window creation.

Can look at https://github.com/alacritty/alacritty/blob/ad3ebba53233fdc61584b341be970a1828d09013/alacritty/src/display/mod.rs#L386 and follow the logic in it...

[QuantumBadger]

Thanks @kchibisov!

I've found the event details in the Wayland protocol design here:

https://gitlab.freedesktop.org/wayland/wayland/-/blob/master/protocol/wayland.xml#L2595

So it sounds like we may (or may not) get a scale factor event from the window manager some time after the window is created.

I'd like to continue supporting setting the physical window size in Speedy2D, so I'll probably look for a workaround to avoid passing the problem on to users (possibly waiting for the scale event with a timeout of a few seconds, and hiding the window in the meantime).

Between this and the lack of fractional scaling, it's a shame Wayland is designed this way.

But in general, don't use scale factor of some monitor on Wayland as a scale factor

Is this because it's just not possible to query the scale of the monitor itself on Wayland?

[kchibisov]

So it sounds like we may (or may not) get a scale factor event from the window manager some time after the window is created.

That's right, that's why you must assume scale factor of 1.

Is this because it's just not possible to query the scale of the monitor itself on Wayland?

No, that's because you don't know on which monitor your window will be, until you draw into it.

I'd like to continue supporting setting the physical window size in Speedy2D, so I'll probably look for a workaround to avoid passing the problem on to users (possibly waiting for the scale event with a timeout of a few seconds, and hiding the window in the meantime).

Just do what alacritty is doing, it's setting physical size and works fine for years here.

[kchibisov]

This issue can't be fixed for all setups, however it can be fixed for some setups.

See #3187 given that it tels exactly what to do.