Initial window size not correct on Linux

[andrewdavidmackenzie]

Is your issue REALLY a bug?

• My issue is indeed a bug!
• I am not crazy! I will not fill out this form just to ask a question or request a feature. Pinky promise.

Is there an existing issue for this?

• I have searched the existing issues.

Is this issue related to iced?

• My hardware is compatible and my graphics drivers are up-to-date.

What happened?

I am seeing this problem on Linux but not Macos:

I set an initial window size with Iced::application() in my main()

.window_size(LayoutSelector::get_default_window_size())

of this size:

const BOARD_LAYOUT_SIZE: Size = Size {
    width: 1400.0,
    height: 720.0,
};

The window appears with a size smaller than specified, and scroll bars are shown, "Measuring" window size with a screen capture tool I get these sizes:

Initial: 1289x727 pixels

After changing layout (and size) using my app's layout selector, and then changing back to the same (requested) size, I get:
Resized : 1369x751 pixels

I'm not sure why narrower than requested, and additional height is the window manager/title bar I assume.

Its hard to tell if this is an Iced bug, or the window manager overriding the initial window size.

Is there any way to force the initial window size?

This is running on Pop! with Cosmic Desktop, using crates.io release 0.13.1

Code can be found here

What is the expected behavior?

The initial window size is the requested window size (or slightly adjusted as we see above), that coincides with the size achieved when using window_resize() later and the window displays without the need forscrollbars.

Version

crates.io release

Operating System

Linux

Do you have any log output?

N/A

[andrewdavidmackenzie]

I was wondering if you were able to reproduce this possible bug (or discard it as being due to window managers), or if you needed help reproducing it?

[stevenxxiu]

I had the same issue under X11. This appears to be a winit feature. You may be interested in looking at https://docs.rs/winit-gtk/latest/winit/dpi/index.html#how-is-the-scale-factor-calculated.

Set the environment variable WINIT_X11_SCALE_FACTOR=1 to remove the scaling.

[andrewdavidmackenzie]

Will try that. Is there a way to pass 1.0 (or disable scaling) programatically, that iced could use to avoid this behaviour?

Do you know how the iced scale factor interacts with this, or it uses this?

If iced uses this, I wonder if setting scale factor explicitly to 1.0 could help?

[andrewdavidmackenzie]

OK, I confirmed that neither:

• Using .scale_factor(|_| 1.0) on iced::Application when starting app in main
• setting WINIT_X11_SCALE_FACTOR=1 when running app

solve the problem as reported.

[andrewdavidmackenzie]

Recently I noted that when running on PiOS (on the Pi directly) this doesn't happen. This could mean it's related to the Window Manager, desktop or X11 vs. Wayland.