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.

There are only two real solutions and a mid-way:

• Port the Cpp bindings from Dear ImGui to C# and target them to specific libraries.
• Make a custom c lib that conditionally compiles to the target platform and generate bindings for it.
• A mid-way solution would be to simply use the backends that cimgui provides (D3D11, OpenGL3, Vulkan, SDL2, GLFW).

[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