SDL3 + GPU backend

[PMarcL]

SDL3 was recently officially released (see the 3.2.0 release) along with a nice new GPU API. It would be nice to add the ImGui SDL3+GPU backend to zgui.

Prototype

I have a working prototype in my fork here and here's an example that makes use of it. I learned a few things along the way:

• I updated all the ImGui C++ files under libs/imgui to version v1.91.8 since it's the first ImGui release since SDL3 came out and also because the backend for SDL3+GPU API didn't existed in v.1.91.0.
  • One thing to note is that breaking changes were introduce by 214977e in between those versions.
• The API to render for other backends seems to consist of a single draw function. For the SDL3+GPU backend, I had to break it into three functions, render (to invoke ImGui::Render), prepareDrawData and renderDrawData. This is because at least prepareDrawData and renderDrawData must be called at different point when rendering with the GPU API (more details in the backend header file here).
  • I experimented a bit and it seems like render and prepareDrawData could be combined into one call. A possibly better API for this backend could be prepareDraw and draw function.

Questions

• How disruptive is it to upgrade ImGui to a newer version? I'm not familiar with the other libraries used in this repo (ImGui test engine, ImPlot, etc.) so I wonder if only updating ImGui will break something else.

[nfginola]

On how disruptive it may be to upgrade ImGUI to a newer versions, some backend initialization parameters have changed. These are trivial to fix but worth mentioning.
One example for Vulkan:
Addition of Descriptor Pool Size (1.91 vs master):
https://github.com/ocornut/imgui/blob/8199457a7d9e453f8d3d9cadc14683fb54a858b5/backends/imgui_impl_vulkan.h#L71
https://github.com/ocornut/imgui/blob/e4db4e423d78bce7e6c050f1f0710b3b635a9871/backends/imgui_impl_vulkan.h#L76

With the way backends are exposed in zgui, I think the intent was to have freedom to not be constrained to a single unified interface various ImGUI calls for rendering, which in hindsight works well here as there's an exception with SDL3 (Imgui_ImplSDLGPU_PrepareDrawData) you mentioned. For this I am under the impression we can take the liberty of exposing as we wish, of course minimizing the exposed API surface area if it makes sense.

On the topic of disruption, as long as there's no breaking changes for ImGUI that prevents the other libraries from building, I think upgrading only ImGUI is fine. If there are functional changes in ImGUI that affect the libraries that consume it and produce bugs, then upgrading them to latest version (if any) on request is the only sane solution without having to eye for breaking changes across all of the libraries.

The other libraries are not as actively maintained as ImGUI, so releases are sparse. Usually we can assume they keep working with new released versions of ImGUI, until they suddenly don't.

Largely, ImGUI does a good job to not break backwards compatibility. I think there's two alternatives here:

• When upgrading ImGUI version, grab latest released version of other consuming libraries (if any).
• Just upgrade ImGUI ensuring other libraries build.