Wrong size when resizing window on MacOS Sonoma (Beta)

[zmarlon]

When I resize my window on MacOS Sonoma, I get the following window size as my new size: 4294967295x4294967295.
This does not look like valid values to me.

I'm not sure if it's a macOS or winit bug at this point, but I still thought I'd open an issue in case others encounter the same problem.

[marko-lazic]

Experienced a similar issue after upgrading to the macOS Sonoma developer beta in my Bevy 0.10.1 app.

2023-06-20T20:48:50.569511Z  INFO bevy_winit::system: Creating new window "Bevy App" (0v0)
2023-06-20T20:48:50.598642Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 14.0 ", kernel: "23.0.0", cpu: "Apple M1 Pro", core_count: "10", memory: "16.0 GiB" }
2023-06-20 22:48:50.615 ccc[12532:905455] CAMetalLayer ignoring invalid setDrawableSize width=4294967295.000000 height=4294967295.000000
2023-06-20T20:48:50.616179Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default    
thread 'Compute Task Pool (1)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
      note: label = `main_texture_a`
    Dimension X value 4294967295 exceeds the limit of 16384

I'm looking for a workaround at this point.

[marko-lazic]

As a temporary workaround I run my app with WindowMode::BorderlessFullscreen as opposed to default Windowed.

[weykon]

fn main() {
    App::new()
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                mode: WindowMode::BorderlessFullscreen,
                ..default()
            }),
            ..default()
        }))
        .add_startup_system(setup)
        .run();
}

I try this succeed on official 3d scene example code 3d scene

[T-Damer]

Yup @weykon workaround works for me, interesting why it can't handle windowed mode 🤔

[rdinkel]

It occurred after already being on sonoma beta 2 but later updating the command line tools and xcode to Command_Line_Tools_for_Xcode_15_beta_2 and xocde beta 2

[madsmtm]

It would be nice to get a winit+wgpu reproducer, a bit hard to tell if this is a Bevy-specific issue or not?

[rdinkel]

I used to try out this example https://github.com/StarArawn/bevy_ecs_tilemap/blob/main/examples/mouse_to_tile.rs of this lib https://github.com/StarArawn/bevy_ecs_tilemap/tree/main

OS: MacOS 14 beta 2 on M1
Command_Line_Tools_for_Xcode_15_beta_2
xocde beta 2

rustup 1.26.0 (5af9b9484 2023-04-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.70.0 (90c541806 2023-05-31)`

Log:

2023-07-03T11:24:34.853647Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 14.0 ", kernel: "23.0.0", cpu: "Apple M1", core_count: "8", memory: "16.0 GiB" }
2023-07-03 13:24:34.893 mouse_to_tile[98174:3742604] CAMetalLayer ignoring invalid setDrawableSize width=4294967295.000000 height=4294967295.000000
2023-07-03T11:24:34.894587Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default    
thread 'Compute Task Pool (0)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
      note: label = `main_texture_a`
    Dimension X value 4294967295 exceeds the limit of 16384

', /Users/X/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.15.1/src/backend/direct.rs:3024:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'Compute Task Pool (0)' panicked at 'A system has panicked so the executor cannot continue.: RecvError', /Users/X/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.10.1/src/schedule/executor/multi_threaded.rs:194:60
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /Users/X/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_tasks-0.10.1/src/task_pool.rs:376:49
thread 'Compute Task Pool (0)' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', /Users/X/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_render-0.10.1/src/pipelined_rendering.rs:136:45
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/X/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_tasks-0.10.1/src/task_pool.rs:376:49

[jinleili]

I believe this is not an issue with wgpu or bevy. It can be reproduced 100% on macOS Sonoma, unless max_inner_size is set. gfx-rs/wgpu#3915

[madsmtm]

I thinkthe problematic part would be the call to visibleRect inside the frame change notification:

winit/src/platform_impl/macos/view.rs

Line 233 in 81fd394

let rect = self.visibleRect();

I think this call for some reason now returns a null rectangle, which we fail to check?

My Mac is not new enough to do the verification on that OS myself, though perhaps we can just skip the event if the view rectangle is invalid?

Maybe someone could put a dbg! around the rect, and then test it on just a winit example? And maybe together with the output of the view's frame? (Note: you can disable the tracing logs with .with_level(log::LevelFilter::Info) on SimpleLogger).

[RoyalFoxy]

What is the status of this bug? I still have the issue that only the workaround with WindowMode::BorderlessFullscreen seems to work.

[Zk2u]

Working fine on Sonoma until I attempted to run it on an external monitor and got this error.

[T-Damer]

Yeah, I tested with external monitor as well, maybe they fixed it in new betas for internal monitor 🤔

[RoyalFoxy]

Nope I still get this error when not having my external monitor attached.

Here's the main.rs file of the project I used

use bevy::{
    prelude::*,
    sprite::MaterialMesh2dBundle,
    window::{PrimaryWindow, WindowMode},
};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                //mode: WindowMode::BorderlessFullscreen,
                ..default()
            }),
            ..default()
        }))
        .add_systems(Startup, setup)
        .run();
}

fn setup(mut commands: Commands) {
    commands.spawn(Camera2dBundle::default());
    commands.spawn(NodeBundle {
        style: Style {
            width: Val::Percent(100.0),
            height: Val::Percent(100.0),
            ..default()
        },
        background_color: Color::RED.into(),
        ..default()
    });
}

fn testing(window_query: Query<&Window, With<PrimaryWindow>>) {
    let window = window_query.single();

    println!("{}", window.width());
    println!("{}", window.height());
}

this results in the following error which I think is almost the exact same as the one posted at the beginning of this issue

2023-08-21T07:30:48.084903Z  INFO bevy_render::renderer: AdapterInfo { name: "Apple M2 Pro", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
2023-08-21T07:30:48.096895Z  INFO bevy_winit::system: Creating new window "Bevy App" (0v0)
2023-08-21T07:30:48.128486Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 14.0 ", kernel: "23.0.0", cpu: "Apple M2 Pro", core_count: "10", memory: "16.0 GiB" }
2023-08-21 09:30:48.175 crawler[73141:2004826] CAMetalLayer ignoring invalid setDrawableSize width=4294967295.000000 height=4294967295.000000
2023-08-21T07:30:48.176575Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (2)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
      note: label = `main_texture_a`
    Dimension X value 4294967295 exceeds the limit of 16384

Ohh and it works if you uncomment the line that enabled fullscreen...

[madsmtm]

All, please state your macOS build number, in case the issue have been fixed in a newer beta.

I tried running this myself in a virtualized setup with macOS 14 Beta 6 build 23A5328b, and could not reproduce the issue; but since this was a virtualized setup, I didn't have the ability to connect an external monitor, so that may still be an issue.

It would be immensely helpful if someone could try the following patch, with a cargo run --example window in this repository, and then give the output of those two debug statements.

diff --git a/src/platform_impl/macos/view.rs b/src/platform_impl/macos/view.rs
index c8e34e4aa..719ec0b92 100644
--- a/src/platform_impl/macos/view.rs
+++ b/src/platform_impl/macos/view.rs
@@ -224,7 +224,8 @@ declare_class!(
                 self.removeTrackingRect(tracking_rect);
             }
 
-            let rect = self.visibleRect();
+            dbg!(self.frame());
+            let rect = dbg!(self.visibleRect());
             let tracking_rect = self.add_tracking_rect(rect, false);
             self.state.tracking_rect.set(Some(tracking_rect));
 

[ptxmac]

The error is still present in the latest developer beta (14.0 Beta (23A5328b))
Here's the debug output:

TRACE [winit::platform_impl::platform::view] Triggered `frameDidChange:`
[src/platform_impl/macos/view.rs:227] self.frame() = CGRect {
    origin: CGPoint {
        x: 0.0,
        y: 0.0,
    },
    size: CGSize {
        width: 128.0,
        height: 128.0,
    },
}
[src/platform_impl/macos/view.rs:228] self.visibleRect() = CGRect {
    origin: CGPoint {
        x: -8.988465674311579e307,
        y: -8.988465674311579e307,
    },
    size: CGSize {
        width: 1.7976931348623157e308,
        height: 1.7976931348623157e308,
    },
}
TRACE [winit::platform_impl::platform::view] Completed `frameDidChange:`

[ptxmac]

I currently use the following hack in my project:

(as part of my event handler)

        WindowEvent::Resized(physical_size) => {
                    if physical_size.width == u32::MAX || physical_size.height == u32::MAX {
                        // HACK to fix a bug on Macos 14
                        return;
                    }
                    state.resize(*physical_size);
                }

[madsmtm]

Thank you, that's very useful!

I had been wondering in the past why we're using visibleRect instead of frame, it seemed like the cases that visibleRect takes care of are basically never relevant for winit, since the view is always the root view, and never clipped by any superviews; and besides, since we only return the size of the rectangle (and not the position), it would still be useless in the cases where it was relevant.

I need to do a little bit more testing, but otherwise I think I'm ready to just replace visibleRect with frame, and be done with it.

[madsmtm]

Since this is affecting a lot of people, we're doing a backport and releasing v0.28.7, see #3118.

[madsmtm]

Okay, v0.28.7 has been released.