Proposal to Include Backend Bindings in CSharp Libraries for Reusability

[JunaMeinhold]

I've received some suggestions about including backends in CSharp bindings (#16) to make it easier for developers to reuse existing, well-tested backends (e.g., for Windows, macOS, and Linux) from CImGui, rather than having to create custom solutions from scratch. This could help streamline development across platforms when using CSharp bindings.

The backends would be shipped in a extra nuget package (or multiple) to stay dependency free.

• Win32
• GLFW
• SDL2
• OpenGL2
• OpenGL3
• Vulkan
• D3D9
• D3D10
• D3D11
• D3D12
• Metal
• OSX
• Android

[J8-8N]

Hello,

I didn't want to put this burden on you specifically.
I wonder if your Hexa.NET.Raylib isn't already a solution to this. Couldn't it be a cross-platform base layer?

[JunaMeinhold]

No problem, i already found a way.

(see io.BackendXXX)

[JunaMeinhold]

The only problem i have is I don't know if that requires me now to ship sdl2 and glfw dlls on linux/unix based systems on windows i can just do /DELAYLOAD: but i don't have that much experience with coding on linux/unix

[J8-8N]

Awesome thank you! Please make it GLFW 3.4+ if they need included

[JunaMeinhold]

I will simply use the vcpkg version

[JunaMeinhold]

I have a problem i can only embed the backends into cimgui and not as separate shared lib which isn't a good solution, since that means every lib like sdl2 and glfw3 are by that dependencies. A solution for that problem would be to convert the backends to cimgui and then dynamic link to cimgui, but that would need a major change in those backend files, it might be possible to automate but that would need time.

[JunaMeinhold]

Update: i found a workaround.

[JunaMeinhold]

Any idea why this happens? The glu32.lib exists clearly for arm64. It only happens on arm64 for windows, when i build locally on my machine everything works.

https://github.com/HexaEngine/cimgui_impl/blob/master/.github/workflows/main.yml
https://github.com/HexaEngine/cimgui_impl/actions/runs/11314077852/job/31463600870

[JunaMeinhold]

Next Question, should i make independent packages for each backend type or a all in one package or maybe both?

[J8-8N]

Sorry I can't help, I'm an embedded C dev dealing mostly with highly constrained resources and discovering CSharp, GUI and Github tools.

Are the backends drop-in replacement for each other? I guess that's the core question to decide how to package them. And are these split in two categories likes Windowing and Rendering? Which would allow using GLFW+(D3D or GL3 or Metal) in which case having these splits makes a lot of sense but comes at the cost of a common Windowing or Rendering interface.

Unrelated and a bit premature but could you consider adding some functions of GLFW like setWindowHint, setWindowAttrib and their getWindowHint and getWindowAttrib equivalent so users can configure stuff a little from CSharp? Thank you very much

[JunaMeinhold]

The only thing that's to consider in packing them is that some uses prefer SDL2 over GLFW or vice versa you definitely don't need both at the same time. And the backend for Win32 (another windowing) has no dependencies that have to be shipped along the implementation dll means i can just ship it as base same goes for D3D11 D3D12 OpenGL Vulkan they are all part of the operating system/graphics driver. The only thing that would happen if you call D3D11 eg windows related functions on linux or any other os that's not windows then it would crash, but luckily you can check which os you are on in c# with:

RuntimeInformation.IsOSPlatform(OSPlatform.Windows)

I will not add functions for GLFW for that you have to go grab any wrapper that allows access to the underlying pointers like Silk.NET.GLFW does, same goes for SDL2, Silk also has a SDL2 lib available but i have one too. I will probably make a wrapper for GLFW soon too, but they will not be shipped with the package, to satisfy users that might prefer lib x over y.

[J8-8N]

So the block of code from main() here https://github.com/ocornut/imgui/blob/master/examples/example_glfw_opengl3/main.cpp#L38 to ImGui_ImplGlfw_InitForOpenGL (line 86) will be handled by the user with a third-party GLFW binding?

[JunaMeinhold]

yeah just like this

[JunaMeinhold]

Small update: i made bindings for GLFW (3.4) https://github.com/HexaEngine/Hexa.NET.GLFW

[JunaMeinhold]

I uploaded the backends on nuget and source is available in backends branch.

Important note: you have to call XXX.SetCurrentContext before using any of the backends.
Like this:

[J8-8N]

Hello and congratulations, this is awesome.

D3D11 example, OpenGL3 example and GLFW example all worked on the first try!

I'm trying to bruteforce a GLFW/OpenGL3 ImGui example:

But Hexa.NET.GLFW.CreateWindow returns an Hexa.NET.GLFW.GLFWwindowPtr
then Hexa.NET.ImGui.Backends.GLFW.ImGuiImplGLFW.InitForOpenGL expects an Hexa.NET.ImGui.Backends.GLFW.GLFWwindowPtr instead
and I'm unsure how to resolve this best.

Thank you!

[JunaMeinhold]

I'll upload a minimal example soon. And add some changes too, but what you do basically is this then

[JunaMeinhold]

Here: https://github.com/HexaEngine/Hexa.NET.ImGui/blob/backends/ExampleGLFWOpenGL3/Program.cs

[J8-8N]

Awesome thank you very much. Tried the example on Windows and Linux so far but have not tried anything fancy yet

[JunaMeinhold]

I tested it with my widget collection which has many custom widgets and it seems to work fine.

[J8-8N]

Would you have an opinion on a GLFW+DirectX11 combo? It's in the CImGui examples but not in the ImGui examples and I wonder if there's a good reason for that. https://github.com/cimgui/cimgui/tree/docking_inter/backend_test/example_glfw_dx11

In other words, ImGui examples provide GLFW+(Metal, OGL2, OGL3, Vulkan, WGPU) examples so pretty much any combination possible but not GLFW+Dx11 and I wonder if it's a "willed omission".

Thank you

[JunaMeinhold]

Of course you can do GLFW+D3D11 but you have to make something like this https://github.com/HexaEngine/Hexa.NET.ImGui/blob/master/ExampleD3D11%2FD3D11Manager.cs and the setup is just larger in comparison to GLFW+GL and SDL2 is better for game engines. While GLFW is just for windowing SDL2 is a multimedia library.

[JunaMeinhold]

And i can't test the metal backends anyway. Since i don't own a mac. And creating examples for all combinations is just annoying to do. Vulkan in particular is very verbose.

[J8-8N]

Thank you very much!

You might be interested to add this quirky bugfix from the GLFW examples back:

[JunaMeinhold]

(it's a bit off topic but still relevant)
Thoughts on my new wrapper, is there anything missing? (I don't use OpenGL that much)
https://github.com/HexaEngine/Hexa.NET.OpenGL