Miniquad without the graphics abstraction?

[EriKWDev]

I love the minimalistic approach you have to library design with all the quad- and nano- crates.

winit is a huge library currently and miniquad provides everything I need for input handling and window opening, it is however tightly coupled to OpenGL context creation, Metal, as well as the abstraction provided on top of that.

It would be awesome to be able to have the windowing and input layers of miniquad without the graphics abstraction so that one could still chose something differnet like Vulkan or WGPU.

Would it be of interest to perhaps separate these parts of miniquad into its own crate while still providing low-level api enough so that miniquad can be implemented on top of it?

[seivan]

Actually, I was wondering why the rendering portions aren't being done with wgpu - wouldn't it be easier and more portable?

It would also solve the issues with post-processing only being implemented for OpenGL without having to write separate shaders.

[EriKWDev]

The goals of miniquad are not strictly ease of implementation, but rather to use what the operating systems already provides us and to avoid dependencies to a great extent to keep compile times rapid.

I can also relate to the joy of having complete control over as much as possible, as well as to the satisfaction of knowing how to implement all this stuff.

The nice thing about my proposal here is that having a tiny platform abstraction for input handling and window control, rendering abstractions like the one miniquad provides could be implemented on top of it be it with OpenGL/Metal/Vulkan/Wgpu etc

[tjpalmer]

There was a recent commit with WebGL2 support, by the way. And in my current project, I'm using naga to translate spirv to glsl 300 es (or presumably could also translate to metal) for shader portability. Naga is adding about 650k of weight in my stripped down wasm, but it's nice to have shader portability.

[EriKWDev]

Any feedback on this @not-fl3?

Would it be feasable/desireable to create a windowing/input library for the 'native' parts of miniquad?

I can see some worries which might be feature-creep in such a separate library that are not needed by miniquad. One such example could be specific paths for Vulkan context creation or maybe 'raw-window-handle' integration which miniquad doesn't require but that others, myself included, would probably want.