Window always renders white on Windows 11 in release build.

[neildanson]

I appreciate this may not be an issue with minifb (Windows versions, Graphics driver versions) - but its pretty much my only dependency.

Everything displays correctly in debug builds. Same code works fine in both release & debug on M1 mac.

Any of the examples exhibit this.

Main things I can think of that may impact?

rustc 1.79.0-nightly (ccfcd950b 2024-04-15)

Nvidia 3080, game ready driver 552.22 (april 16 2024)

Edition Windows 11 Pro Version 23H2 Installed on ‎06/‎10/‎2022 OS build 22631.3447 Experience Windows Feature Experience Pack 1000.22688.1000.0

I had a small application that was fine from 1 month ago, no changes in code (probably a windows update and a rustup update).

[emoon]

I would recommend that you try to clone the rust_minifb repo and run one of the examples and see if these works. Such as cargo run --release --example noise and see if it still shows up while or not if you switch between --release and not including it.

[neildanson]

Repro

use minifb::*;

const WIDTH: usize = 320;
const HEIGHT: usize = 240;

fn create_window() -> minifb::Window {
    minifb::Window::new(
        "App",
        WIDTH,
        HEIGHT,
        WindowOptions {
            scale: Scale::X4,
            transparency: false,
            ..WindowOptions::default()
        },
    )
    .unwrap_or_else(|e| {
        panic!("{}", e);
    })
}

fn update_buffers(window: &mut minifb::Window, buffer: &[u32]) {
    window.update_with_buffer(&buffer, WIDTH, HEIGHT).unwrap();
}

fn main() {
    let mut window = create_window();
    let mut buffer: Vec<u32> = vec![0; WIDTH * HEIGHT];

    while window.is_open() && !window.is_key_down(Key::Escape) {
        for i in 0..WIDTH * HEIGHT {
            buffer[i] = 0xff000000;
        }
        update_buffers(&mut window, &buffer);
    }
}

In Release

In Debug

[neildanson]

I would recommend that you try to clone the rust_minifb repo and run one of the examples and see if these works. Such as cargo run --release --example noise and see if it still shows up while or not if you switch between --release and not including it.

Interestingly this works.

[neildanson]

Also interestingly however is that the version in master (cargo toml 0.25) doesnt match the released version (also 0.25) (ie missing window.set_target_fps(60);)

Could it be fixed since the latest published to crates.io?

[neildanson]

I can confirm that adding

minifb = { git = "https://github.com/emoon/rust_minifb.git", rev = "633e6cd4f8f55fd9cbedc461976dde0f408bea35" }

as my dependency everything renders fine

[emoon]

Unsure, I can make a new release later today.

[neildanson]

No rush on my account - its good to know its fixed and I'm unblocked by specifying the revision.

Thanks for such an awesome project :)

[emoon]

Thanks :)

[bunnie]

Just saw this issue - now that Rust 1.78 is live, we're also seeing the problem on stable. We'll also pin to the git version as well until a new release is up, but leaving a note here in case other users are encountering the same problem.

[bunnie]

Some function is also deprecated in the new release -- so the switch over isn't exactly clean, but, I'll also check in the code change to comply to the deprecation notice as well when I rev things.

[Cyborus04]

I wonder what changed from 1.77 to 1.78 that made this happen?

[emoon]

I will sort out a new release today

[bunnie]

I wonder what changed from 1.77 to 1.78 that made this happen?

A couple changes specifically impacting windows: https://github.com/rust-lang/rust/pull/115141/ or this https://github.com/rust-lang/rust/pull/112267/

Nothing leaps out at me as the culprit, there were also some changes to locking that maybe introduced a race condition? Either way, top of main branch works.

Thanks @emoon for the support!

[emoon]

0.26 has now been published

[bunnie]

thank you ~~~

[neildanson]

I think there may still be (at least 1) issue on Windows WRT mouse. I'll try to knock up a small repro this morning

[neildanson]

use minifb::{MouseButton, MouseMode, Scale, WindowOptions};

const WIDTH: usize = 28;
const HEIGHT: usize = 28;

fn create_window() -> minifb::Window {
    minifb::Window::new(
        "Mouse App",
        WIDTH,
        HEIGHT,
        WindowOptions {
            scale: Scale::X32,
            ..WindowOptions::default()
        },
    )
    .unwrap_or_else(|e| {
        panic!("{}", e);
    })
}

pub fn main() {
    let mut window = create_window();
    let mut buffer = vec![0; WIDTH * HEIGHT];
    let mut pattern = vec![0.0; WIDTH * HEIGHT];
    while window.is_open() && !window.is_key_down(minifb::Key::Escape) {
        if let Some((x, y)) = window.get_mouse_pos(MouseMode::Discard) {
            let screen_pos = ((y as usize) * WIDTH) + x as usize;

            if window.get_mouse_down(MouseButton::Left) {
                buffer[screen_pos] = 0x00ffffff;
                pattern[screen_pos] = 1.0;
            }

            if window.get_mouse_down(MouseButton::Right) {
                buffer[screen_pos] = 0x00000000; 
                pattern[screen_pos] = 0.0;
            }
        }

        window
            .update_with_buffer(&mut buffer, WIDTH, HEIGHT)
            .unwrap();
    }
}

If you run in debug mode, you get the worlds worst drawing app. Well, technically if you run it in release mode you get the worlds worst drawing app because it doesnt work :)

Adding in a small amount of logging shows that get_mouse_down never returns true in release.

[emoon]

I get the same result with running the mouse example on Windows. I will investigate

[emoon]

I have pushed a workaround for the issue. I'm not really sure what is going on yet tho.

Edit: version 0.27 has been released with the fix, but I need to investigate the root cause of it.