rust_minifb: update_with_buffer hangs on macOS while you resize the window

gif minifbResize

code

use minifb::{Window, WindowOptions};

fn main() {
	let mut window = Window::new(
		"rust-raytracer",
		10,
		10,
		WindowOptions {
			resize: true,
			..WindowOptions::default()
		}
	).expect("Couldn't create window");

	while window.is_open() {
		let (width, height) = window.get_size();
		let mut buffer: Vec<u32> = vec![0xFFFFFF; width * height];

		buffer[width + 1] = 0xFF0000;

		window.update_with_buffer(&buffer, width, height).unwrap();
	}
}

Observe how the red pixel gets large while I drag to resize the window bigger, but as soon as I release the left click, the buffer updates and the red pixel returns to normal size

Is it possible to fix this?

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 44 (41 by maintainers)

Most upvoted comments

I think in order to solve this quite a bit of the internals of minifb has to be changed on how it drives the update loop. I’m not sure if it’s worth it or not.

AFAICT, this issue cannot feasibly be solved without moving away from polling which is like 80% of minifb’s API. Context switching / coroutines / whatever are not reliable or portable enough to use here either unfortunately.

I have considered using winit in the past, but the problem is that winit it isn’t really that “mini” and has quite a bunch of dependencies and I want minifb to be fast to compile and easy to use (no need for setting up extra callbacks for event handling)

minifb is good at what it does. It gets a buffer on screen and lets you poll for some basic inputs. But yeah, this would require a huge shift in minifb’s API and probably isn’t worth it, since that isn’t what this crate is for.

That is indeed odd. I will investigate this evening.

Hi,

No there is currently no workaround for it.

Thanks! That is good to know. My initial vision for minifb was just an simple library to be used for experemints when wanting to plot some pixels (the initial api only had open window with fixed size check for esc and close window) over the years it grew into a more feature rich api that supporting resizing, menus, etc.

Oh well, I’m happy people still find it useful even if it has it’s sets of issues 😃

Thanks! and agreed. I will perhaps experimint with it some day when I feel up to it and see if I can come up with something that would work.

I just tested the example https://github.com/emoon/rust_minifb/blob/master/examples/multi.rs under macOS and it runs fine at least

Interesting, didn’t even know that was an example. Anyway, if you ever do want to try implementing the “thread notification” approach, you would probably have to separate event loops and windows.

You’d create your event loop, create your windows on that event loop, specify a… callback function… for each window (D:::😃 and then run the event loop which will block the main thread forever.

At least, that’s how I’d imagine it working.

It’s worth looking into, but not worth implementing right now imho. After all, minifb is not broke 😃

@emoon It’s still helpful to discuss so that someone (like me) can open a pull request one day.

I get it