ignore the window arc on macos

[mockersf]

Objective

• Since Introduce a WindowWrapper to extend the lifetime of the window when using pipelined rendering #12978, apps hang son macOS when closing the window
• See macos: app hangs after pressing window close button #13208. This is not a fix but a workaround

Solution

• Ignore the window arc. The original issue didn't happen on macOS anyway

[ids1024]

So with this change, there's a RawHandleWrapper for a window that no longer exists?

That means the RawWindowHandle contains a dangling pointer, which is definitely an issue if its actually used anywhere after that.

Not necessarily bad for a temporarily workaround (given this issue already existed) but definitely warrants more investigation.

[alice-i-cecile]

I don't hate this as a workaround. Messy though, and I'd obviously prefer a real fix.

[rparrett]

I can confirm that this fixes the issue, but I have not been following along with the relevant changes.

I am seeing this error spam when closing windows now, however:

2024-05-04T01:24:08.745268Z  INFO bevy_winit::system: Creating new window "App" (Entity { index: 0, generation: 1 })
2024-05-04T01:24:10.548038Z  INFO bevy_window::system: No windows are open, exiting
2024-05-04T01:24:10.549105Z  INFO bevy_winit::system: Closing window Entity { index: 0, generation: 1 }
2024-05-04T01:24:10.566197Z  INFO bevy_window::system: No windows are open, exiting
2024-05-04T01:24:10.567983Z ERROR bevy_winit: Failed to send a app exit notification! This is a bug. Reason: sending on a full channel
2024-05-04T01:24:10.568591Z ERROR bevy_winit: Failed to send a app exit notification! This is a bug. Reason: sending on a full channel
2024-05-04T01:24:10.568675Z ERROR bevy_winit: Failed to send a app exit notification! This is a bug. Reason: sending on a full channel

The errors go away if I revert 15687b5.

[alice-i-cecile]

#13203 should fix the warning spam: that's a cross platform problem that's not particularly related.

[ids1024]

I've done a bit more investigation of the issue here, with some comments about it on #13208.

It looks like the issue that the winit::Window is dropped on a non-main thread. On macOS, this executes on the main thread and blocks on completion of that. But it seems something is running on the main thread and blocking it, so winit::EventLoop/CFRunLoop can't make progress and actually run that?

Not sure exactly have bevy is managing what the main thread is doing here, but this sounds non-trivial to fix. So this workaround may be needed for now.

[alice-i-cecile]

"Resources that must be dropped on the main thread" is exactly what NonSend data is for.

[mockersf]

This isn't a resource, it's a component... so it would mean we can't put the window in a component

[ids1024]

Dropping the winit::Window from off the main thread isn't a problem in itself, but it is a problem if something is blocking the winit::EventLoop. Then it deadlocks. (This is also true if another thread tried to call other winit methods.)`

[mockersf]

closing in favour of #13236