Problem with `winit_multithread` example on macOS
Technical details & libs versions: Libs:
winit = "0.30.7"
softbuffer = "0.4.6"
Machine:
MacBook Pro with M3
macOS: Sonoma 14.6.1
Hi! During developing software rendering I've decided to switch making render itself in separated thread and attempted to run example from examples/winit_multithread.rs, but got a problem that program is "stuck" at let size = window.inner_size();:
starting thread...
making surface...
waiting for render...
In docs for inner_size is see that
Platform-specific iOS: Can only be called on the main thread.
But is it also applied to macOS platform?
I tried to remove fetching window size and it works (I've added a little code to see that different thread rendering works):
fn render_thread(
window: Arc<Window>,
do_render: mpsc::Receiver<Arc<Mutex<Surface>>>,
done: mpsc::Sender<()>,
) {
let mut c: u32 = 0u32;
loop {
println!("waiting for render...");
let Ok(surface) = do_render.recv() else {
println!("main thread destroyed");
break;
};
// Perform the rendering.
let mut surface = surface.lock().unwrap();
let (Some(width), Some(height)) = (NonZeroU32::new(1024), NonZeroU32::new(1024)) else { todo!() };
surface.resize(width, height).unwrap();
let mut buffer = surface.buffer_mut().unwrap();
for y in 0..height.get() {
for x in 0..width.get() {
let red = (x + c) % 255;
let green = (y + c) % 255;
let blue = (x * y + c) % 255;
let index = y as usize * width.get() as usize + x as usize;
buffer[index] = blue | (green << 8) | (red << 16);
}
}
println!("presenting...");
buffer.present().unwrap();
// We're done, tell the main thread to keep going.
done.send(()).ok();
c += 1;
}
}
iOS: Can only be called on the main thread.
But is it also applied to macOS platform?
No, it can be called from all threads on both platforms (the docs are a bit outdated on iOS), but it will block on both platforms too, waiting on the main thread to fetch the surface size.
My recommendation would be to communicate surface size changes through a channel or a mutex or something.
This issue seems to match what we wanted to achieve with #237, and generally rethinking when to forward window resizes into softbuffer (or not, to achieve hardware scaling).
@madsmtm, yeah, I already figured it out, just wanted to highlight that recently updated example does not work 😅