Regression around window size

[alec-deason]

Bevy version
The problem was introduced in 6b004f7

Operating system & version

Arch Linux with Wayland via Sway.

What you did

Run the button example via cargo.

What you expected to happen

I expect the gray background to fill the window with the button in the center.

What actually happened

The background fills the upper left 2/3 of the window with the rest solid black. When the window resizes, the content also resizes but is always limited to the upper left 2/3s of the window. The button responds to mouse events when the cursor is in the location where the button should be but not when the cursor is where the button is shown to be. I see equivalent behavior with other examples.

Additional information

This is the example running fullscreen. Though the cursor isn't visible in the screen shot it is located near the lower right corner of the gray area, where the button should be. You can see that the button is in it's hovered state.

Here's what sway thinks my screen is, if that's useful:

$ swaymsg -t get_outputs
Output eDP-1 'Chimei Innolux Corporation 0x14C9 0x00000000' (focused)
Current mode: 1920x1080 @ 60.007999 Hz
Position: 0,0
Scale factor: 1.000000
Scale filter: nearest
Subpixel hinting: unknown
Transform: normal
Workspace: 1
Max render time: off
Adaptive sync: disabled
Available modes:
1920x1080 @ 60.007999 Hz

[mockersf]

oh shouldn't have changed anything as you have Scale factor: 1.000000...

[mockersf]

how do you go to fullscreen?

• using window decoration?
• from bevy with one of those?
  • window.set_mode(bevy::window::WindowMode::BorderlessFullscreen)
  • window.set_mode(bevy::window::WindowMode::Fullscreen { use_size: true })
  • window.set_mode(bevy::window::WindowMode::Fullscreen { use_size: false })

could you add this system and show me what it's logging before/after going fullscreen?

fn res(windows: ResMut<Windows>) {
    let window = windows.get_primary().unwrap();
    info!("{:?}", window);
}

thanks

[alec-deason]

how do you go to fullscreen?

In that example I use the window manager to do it. But I see the same weird scaling even when it's not full screen. I know that sway always resizes the window immediately after it is created, regardless of whether it's full screen or not. So on my system I will never see a window that hasn't been resized at least once after initialization.

could you add this system and show me what it's logging before/after going fullscreen?

Pre-fullscreen:
button: Window { id: WindowId(00000000-0000-0000-0000-000000000000), width: 382, height: 646, title: "bevy", vsync: true, resizable: true, decorations: true, cursor_visible: true, cursor_locked: false, mode: Windowed, command_queue: [], scale_factor: 1.6666666666666667 }

Post-fullscreen:
button: Window { id: WindowId(00000000-0000-0000-0000-000000000000), width: 1152, height: 648, title: "bevy", vsync: true, resizable: true, decorations: true, cursor_visible: true, cursor_locked: false, mode: Windowed, command_queue: [], scale_factor: 1.6666666666666667 }

Looks like winit thinks my scale factor isn't 1.0?

A weird thing happened while I was testing this. I had 6b004f7 checked out with a few local changes to get bevy to compile with hexasphere (an issue that was fixed in a later commit). I pasted your system into the example and ran it and everything worked normally, the scale looked correct and resizing the window worked as expected including moving back and forth from fullscreen. I thought there must have been something wrong on my system last night that somehow magically fixed itself over night so I moved to the latest master and tried again and got the old broken behavior. I've fiddled around a bit but haven't been able to get it to switch behaviors again. It's unclear to me what's going on.

[mockersf]

where it gets funny is that internally to winit scale_factor for Wayland is an u32 and in the underlying Wayland client it's an i32... so 1.6666666666666667

[alec-deason]

Sorry, wayland is a red herring. I forgot that bevy only has x11 in it's default setup so the examples were actually running in the fallback x11 server rather than native wayland. When I force them to use wayland the scale factor is normal. So the issue is with xwayland somehow.

[alec-deason]

Regardless, of what the underlying issue actually is I can verify that bevy is correctly using the scale_factor reported to it by winit so the problem is upstream. I'm going to close this issue.