The road to 1.0

[emoon]

This crate has now been around for almost 4 years (Nov 22, 2015) so I guess it's time to start moving it towards 1.0 but before that there is some issues I want to be done before.

• [x] #47 (WASM support)
• [ ] #82 (OpenGL support on Linux and Windows)
• [ ] #95 (Some keys not working on macOS)
• [ ] #83 (Correct Aspect ratio handling)
• [ ] #236 (DPI Support)

• More things. Proper scaling without hick-ups for dynamic sized windows.
• Should it be possible to specific RGB(0) ordering of the buffers?
• Should software support be deprecated (Linux only pretty much)
• Also a clean-up of all the remaining issues. I would like to have zero issues (if possible) when hitting 1.0
• More examples of all features.
• Add multi-threaded example
• Add frame-rate limiting example

More suggestions can be added in the comments. I will start adding issues I want to fix for the https://github.com/emoon/rust_minifb/milestone/1 milestone

[tversteeg]

Maybe software support could be a feature?

[sinclairzx81]

@emoon Thanks for all your hard work on minifb, love this crate! Looking forward to the 1.0 release! :D

Should it be possible to specific RGB(0) ordering of the buffers?

This would be a cool feature. I think currently, the buffers in minifb may linearly line up as BGRA (as little endian u32 arrays). Seeing as WASM is listed as an upcoming, it could be worth making note of the browsers ImageData using RGBA ordering as a pretty good rationale for including ordering as a feature.

ImageData.data Read only

Is a Uint8ClampedArray representing a one-dimensional array containing the data in the RGBA order, with integer values between 0 and 255 (inclusive).

I wonder if having the option to define the order as well as being able to submit buffers as Vec<u8> might be possible. This may make it easier to transfer ImageData buffers between the Page and WASM context's without the need to remap the buffer prior to update_with_buffer(...). With the Vec<u8> option added to help avoid the need to transmute between u8 and u32 buffers when setting RGBA values in the buffer. Also, Vec<u8> buffers makes the order super explicit when setting RGB values.

One common use case I expect would be to have the page load images (as RGBA) which are then passed to minifb to present (currently BGRA).

@tversteeg @FloVanGH Thoughts?

// possible Uint8ClampedArray passed from the page.
let mut buffer: Vec<u8> = vec![0; WIDTH * HEIGHT * 4];

let mut window = Window::new(
      "rgba ordering",
      WIDTH,
      HEIGHT,
      WindowOptions {
       order: Order::RGBA,
      ..WindowOptions::default()
    },
);
...
window.update_with_u8_buffer(&buffer).unwrap();

Again, thanks for all the work put into minifb!

[nicolasbauw]

I'm thinking about:

• 32-bit buffer as RGBA instead of 0RGB
• so, the buffer should adequately handle transparency to allow alpha compositing
• Option for the buffer swap to wait VBL for smoother animations (and avoid if we want to wait by counting time)
• accelerated blitting / clear area / clear whole buffer / texture generation / textured surfaces / scaling / rotation and so on functions

[emoon]

I think first 3 points are doable but I think that point 4 is out of scope for minifb.

[nyovaya]

@emoon What do you think about an event loop for 1.0?

[emoon]

Exactly how would that look like? I feel that the current design is simple and nice to use and I wouldn't like to break it if possible.

[nyovaya]

Similar to how SDL and GLFW do this.

[emoon]

GLFW uses callbacks and such for key presses and such. In general I want to avoid callbacks because it makes things more complicated. What are the biggest motivations for this change?

[nyovaya]

Im not talking about callbacks. GLFW uses an event loop: https://docs.rs/glfw/0.38.0/glfw/fn.flush_messages.html We dont need to save all changes in specific structs so we basically dont even process them but rather save the events the server sent and allow the developer to process them like they please to.

[emoon]

Alright. Yeah, that might be a good idea