We already discussed that. Unfortunately, the shaderc tool is a major downside of bgfx, because it completely prohibits cross-compilation. At the moment, cross-compilation is the primary way I am able to support Windows as a first-class platform. I'm also not a fan of their general approach; it does work to an extent, but it's a huge hack, and I don't look forward to having to support it.

One can note that the effort required to port SolveSpace to use bgfx is similar to the effort required to port it to Vulkan. However, Vulkan is a standard API with industry backing, and it actually provides something quite like bgfx: Vulkan Portability Initiative. The VPI implementation that's likely going to be the most usable is gfx-rs.

Of course, until someone (not me) implements a Vulkan rendering backend, the question is moot. Even once that happens, we can still ship two rendering backends until the point where major additions or changes are needed. At that point, the decision to drop ANGLE and MoltenVK in favor of gfx-rs or something similar will be made.

an Emscripten port is in progress

That actually works just fine, because the GL 3 port is carefully written to run on GL ES 2 as well.

Thanks for the info. The reasons are very clear indeed. I would also like to see Vulkan implemented, but it certainly is a big task. I may, however, give a shot in the future (when I'll have less stuff to do, hopefully) as a way to learn Vulkan well, unless the current OpenGL rendering backend is doing particularly complex stuff (I'm still at "beginner+" level on graphics APIs).

Also I guess Vulkan will require GTK4 or Qt, since Solvespace is currently using GTK 3.x, right?

I may, however, give a shot in the future (when I'll have less stuff to do, hopefully) as a way to learn Vulkan well, unless the current OpenGL rendering backend is doing particularly complex stuff (I'm still at "beginner+" level on graphics APIs).

Sounds great! The current OpenGL rendering backend is about as basic as it gets if you're using GL ES 2.

Also I guess Vulkan will require GTK4 or Qt, since Solvespace is currently using GTK 3.x, right?

Unfortunately, yes. And we also can't drop GTK 3 any time soon. I'm not sure how bad exactly it will be, but skimming this document suggests it will be a major nightmare, possibly close to a complete rewrite. Not looking forward to that...

I had a read, not knowing how and how much SolveSpace uses GTK I can't have an opinion on how difficult the port will be (or would be, if another toolkit is choosen).

What would be the best way to start playing around with Vulkan in the short term? If there's even a way (without first completely moving to a toolkit that supports it, I mean).

Also, in alternative to GTK and Qt, given the main reasons for having a "native" toolkit (i.e. not ImGUI or things like that) is native OS integration/look&feel, isn't there any library like libui (which doesn't seem to be in particularly good shape IMHO) that uses native controls for the 3 main OSs and then would allow to have access to the window handle and set up an OpenGL/Vulkan context manually? That would mean using some OS specific code, but in theory after the context is up the discrepancies are gone

I had a read, not knowing how and how much SolveSpace uses GTK I can't have an opinion on how difficult the port will be (or would be, if another toolkit is choosen).

I'm not really sure. The thing about GTK 4 is that as far as I can tell it's not really released yet (it has a version "3.96"...) and I can't even get it installed in Debian, so a port would be... premature.

I suggest looking at the Emscripten port for inspiration. I think you can do this: stub out pretty much everything UI-related other than bare rendering itself, and use something like glfw to set up a Vulkan context. Then you're free to work on those parts alone.

Let me know if you need assistance with that.

that uses native controls for the 3 main OSs and then would allow to have access to the window handle and set up an OpenGL/Vulkan context manually?

Yes. It's called solvespace/src/platform... No, really. Every choice in that space is thoroughly uninspiring. KiCAD uses wxWidgets and pretty much everyone I know who worked on KiCAD tells me to avoid that.

I think you can do this: stub out pretty much everything UI-related other than bare rendering itself, and use something like glfw to set up a Vulkan context. Then you're free to work on those parts alone.

Let me know if you need assistance with that.

Many thanks, if I find some time to experiment with a Vulkan renderer in the next months I'll definitely accept some help in regard. I'm not familiar with the codebase so some insight on where stuff is will definitely be necessary.

I suggest looking at the Emscripten port for inspiration

I'll surely take a look as a first step.

Just out of curiosity, when you talked about gfx-rs, how do you see that being glued with the rest given it's written in Rust? Do you mean using it as a library, thus the language doesn't matter as long as it exports with the C ABI, or would the renderer need to be written in Rust and maybe use the rest of Solvespace as a library or something like that?

Do you mean using it as a library, thus the language doesn't matter as long as it exports with the C ABI

Yes, it exports a subset of the Vulkan ABI. That's what Vulkan Portability Initiative is about. They can run unmodified DOTA 2 against gfx-rs so it should be well good enough.

@whitequark I guess this can be closed since "Bgfx as rendering backend" is no longer relevant? When I'll find some time to play around with Vulkan for rendering I guess I'll open another issue or contact you somewhere else like on IRC?

Sure.