Investigate switching to winit

[emoon]

Over the years minifb has grown quite a bit from it's initial design to be something very basic for prototyping. I built it for just that purpose and has been adding lots of features over the years as per users requests and some of my own as well.

Currently I'm at a point where I'm quite happy with minifb except some things I would like to get in for #101

That being said as people are still requesting features I'm left with some choices:

1. Spend quite a bit of time adding them. While it's great that people like the lib, adding features I really don't use myself takes away time from my other projects.
2. Say no
3. Base minifb window setup on something else to reduce maintenance burden.

These all comes with it's sets of issues and I'm not sure what the best road forward is. I think taking a good look at winit is likely a good idea and was suggested in #44 My biggest worry is really that the minifb API (esp inputs) will have to be re-designed which will be a major breakage to existing users.

[FloVanGH]

I would be really happy if you would start with a implementation based on winit. This would be what we really need for OrbTk. The only true alternative to minifb is pixels. But because of wgpu which it is based on, I have trouble to run it on all platforms e.g. on platforms without Vulkan support. The other alternative is sdl2 but it is a C library and we have also some issue with it.

Minifb was a really good start for OrbTk but it does not provide everything we need e.g. file drop.

Minifb based on winit can be a really advantage for minifb. A stable base, more features / events and more platforms like Android. But I'm with you, it would be break the current api.

I would also be willing to support you in the implementation.

[monomadic]

I've had a few PRs in winit, and even at one point attempting to produce a customised version of it to work with rust-vst2, I can tell you the codebase is very different to rust-minifb. You've already implemented a lot of what it implements, and I think you might have trouble using a framebuffer the way minifb does in all situtations - especially macos gets hairy when trying to customise anything in winit.

You'd get some advantage from things like multi-window, additional support for more esoteric window operation, and I think they have draw-resize support on macos now which is a total pain to implement as the cocoa/coregraphics stuff seems to be hot garbage for threading and drawing.

I would suggest, if this is really something you're interested in, perhaps create a simple framebuffer library that is backend agnostic and purely serves to update the framebuffer (let winit handle eventing and windowing), and keep rust_minifb as its own lib. If you gain lots of experience this way and still decide to create a winit-dependent version, you can morph that new library into one.

You could look into the way glutin or piston or other rust libs have multiple backends, or to be more minimalist, you could write a library that accepts just a *mut c_void (c pointer) from a windowing lib and straps the framebuffer library calls on top of it. Winit allows you to get a window handle through raw_window_handle(): https://docs.rs/winit/0.23.0/i686-pc-windows-msvc/winit/window/struct.Window.html#method.raw_window_handle

I should warn you that adopting winit can bite you, if there's something you really need that winit doesn't provide, you won't have the freedom you have now, the winit team has to share your direction. It is also growing large. The dependencies are huge and it is getting more laborious to compile. One of the things that draws people to minifb is its lightweight fast compile times and resultant binaries - it's great for tiny emulators, linux front ends, etc. If it goes the way of winit I'm not sure what would fill that void. As it is, I'm considering dropping back to C for some of this stuff as the rust ecosystem is producing some super-bloated libraries lately.

Cheers!

[emoon]

Thanks @monomadic for that info. I have heard the same that winit is/getting very big, so minifb wouldn't really be mini anymore.

When I started minifb quite a while ago now it had 3 functions create, update and should_quit and that covered 95% of my use cases.

Now over the years more things has been added making it a more featured library and my problem really is that I don't know where to take it. I think at some point (quite soon) I will just have to say no to more features and target it for a specific need and point to winit for people that actually want a fully featured version.

I think the idea of splitting into a framebuffer library that can support different backends is an interesting one and has been suggested to me before. It's quite a bunch of work in both directions as going back to my initial post.

So yeah... I will have to think more about this.

[monomadic]

If you'd like some assistance or want to bounce ideas around let me know. My overall point was just, if you're looking to completely change the underlying way minifb works (port to winit) it might be a better idea to abstract a new lib instead. I feel minifb serves a purpose that other libraries miss.

[Herschel]

Similarly to @FloVanGH's use case, Ruffle uses wgpu, but unfortunately support is still spotty and people with lower end or alternative devices are unable to use it. So we'd like to experiment with adding a software renderer built on top of raqote, but we'd need some crate to provide a cross-platform way to blit a frame buffer to the window.

pixels also relies on wgpu, nullifying much of the reason for the software renderer.

minifb is fantastic (thank you for your work!), but I wouldn't want the scope of winit's full windowing and event handling to creep into it. So allowing the crate to use separate backends would be ideal, as we could use a minifb-winit backend to continue using our existing winit infrastructure. In this scenario, one would still use winit directly for all input and events, and use minifb to draw and manager the framebuffer. And then the existing simple windowing inside minifb possibly
could be pulled out into a minifb-window subcrate, maintaining the simplicity and ease of use.

[emoon]

Thanks everyone for your input. It seems the way forward (if this is going to be a thing) would be to split minifb so one can built on top of winit and on top of the minifb "core". Right now I don't feel motivated enough to start doing this work, but I will keep this in mind going forward. I will close this now and in cases I start working on it create new issues and reference this one.