Do not send Window to another thread in winit_multithread example

[madsmtm]

The threading implications of accessing a window from another thread are unclear, so Winit chooses to block on the main thread on macOS and iOS.

This means that we have to send the surface width and height to the other thread instead of trying to access it dynamically from the window.

This fixes #249.

[MarijnS95]

The threading implications of accessing a window from another thread are unclear, so Winit chooses to block on the main thread on macOS and iOS.

On a related note, are such functions like Window::inner_size() guaranteed to return the same size until an incoming resize event has been consumed by the event loop?

[madsmtm]

On a related note, are such functions like Window::inner_size() guaranteed to return the same size until an incoming resize event has been consumed by the event loop?

No guarantees that I know of, no. But they should IMO, it makes no sense for you to retrieve a different window size before you've processed the resize event.

[MarijnS95]

The reason I was asking is because egui-winit (unrelated to softbuffer, but interesting because we had a lot of problems with this crate thanks to that roundtrip-to-main for querying the size and other Window properties on MacOS!) queries these window properties when consuming its input State object via State::take_egui_input(): https://docs.rs/egui-winit/0.33.2/src/egui_winit/lib.rs.html#35-45

This to us means a big de-sync if the window size changes before we've handled the event (that we also pass down into egui-winit, no clue why they don't just collect and track those instead but there's no upstream issue yet - maybe I'll create one).