Backend api to better support multiple contexts

[sonoro1234]

Hi Omar,

I think that with some minimal changes the different implementations could be directly used in bindings:

Basically an ImGuiContext should be asociated with the implementation and the following functions exported as C functions: impl_new, impl_delete, impl_Init, impl_NewFrame, impl_Render (which does Render and RenderDrawLists) and also the hook setting functions (Mouse, Key, Char and Scroll) or ProcessEvent in the sdl case or WndProcHandler in dx

This is what I did for example in:https://github.com/sonoro1234/LuaJIT-ImGui/blob/master_auto_implementations/extras/impl_glfw3/imgui_impl_glfw_gl3.h

which is used as in:https://github.com/sonoro1234/LuaJIT-ImGui/blob/master_auto_implementations/examples/minimal_main.lua
or multiwindow
https://github.com/sonoro1234/LuaJIT-ImGui/blob/master_auto_implementations/examples/minimal_multicontext.lua

[ocornut]

I'm not sure I understand, why did you wrap everything into a class with members and not just wrap the 5-6 functions of the original impl code exactly as they exist? What prevents anyone from using the existing functions and wrap them to be accessible in a binding?

[sonoro1234]

I just used a class to made things easier for me: ctx is a member of implementation so I can set global context from the class (see the cpp file)
https://github.com/sonoro1234/LuaJIT-ImGui/blob/master_auto_implementations/extras/impl_glfw3/imgui_impl_glfw_gl3.cpp#L121

[ocornut]

I don’t understand what you are suggesting, and what is the value over wrapping the existing functions.

[sonoro1234]

impl:Set() is used in several places of cpp file to set the class context as the global ImGuiContext. This allows me to have several instances of impl working at the same time, one for each window for example in a multiwindow application. Without the class it would be difficult to implement.
The only way to do it without a class would be to have a impl struct and some functions to work with it, but a class is just simpler for me.

[sonoro1234]

Making implementations multi context ready.

[sonoro1234]

As in https://github.com/sonoro1234/LuaJIT-ImGui/blob/master_auto_implementations/examples/minimal_multicontext.lua

[ocornut]

The focus at the moment is to go toward the Viewport branch which makes multi-context not as useful or necessary, as a single-context is able to handle multiple windows. I’ll keep note however, as the back-end are being refactored, that we could also support what you suggested. However I think it would be best supported by keeping everything opaque and not exposed in the .h file. The back-end could perfect use the imgui context pointer as a key to the back-end instance and transparently handle multi-instances.

[sonoro1234]

the problem would be all those static variables
https://github.com/ocornut/imgui/blob/master/examples/sdl_opengl3_example/imgui_impl_sdl_gl3.cpp#L54
unless they are in a struct or class

[ocornut]

I am saying there’s not reason for putting any of this in the .h file. Whatever structure can stay in the .cpp file.

[sonoro1234]

of course struct could be in the .cpp instead of .h file.
But all the functions will need an extra argument for the implementation struct

[sonoro1234]

The main problem is with opengl data
https://github.com/ocornut/imgui/blob/master/examples/imgui_impl_opengl3.cpp#L33
being static makes imposible to have several windows each one with its own opengl data.

[ocornut]

being static makes imposible to have several windows each one with its own opengl data.

It works perfectly (the viewport branch is using it daily) as long as the OpenGL context are shared contexts. And I see no reason for having non-shared contexts.
PS: Please open separate topics if the discussion is not related to the C bindings.

[sonoro1234]

You are right:
Just saw this http://www.glfw.org/docs/latest/context.html#context_sharing

But the problem remains in g_Window
https://github.com/ocornut/imgui/blob/master/examples/imgui_impl_glfw.cpp#L52

This is related to bindings that also want to bind imgui implementations instead of provide its own implementation. (just dropped bindings from title)

[sonoro1234]

with classes for multiwindow

with standard imgui/examples implementation

[ocornut]

Hello,

Making implementations multi context ready.

This should now be solved by 70c6038 + 4cec3a0.

I confirmed that both OpenGL and DX11 backends worked my test bed.
Platform backends however are not confirmed to fully work but for your specific use case (nested, one blocking the other) it should work with no noticeable issue.

Details (posted in a few threads)

With 70c6038 i have rearranged all backends to pull their data from structures
This commit is rather large and noisy so I tried to make it as harmless a possible and therefore the commit as-is tries to NOT change anything in the backends, which include NOT enabling support for multiple imgui-context.
It was then enabled with a small patch in each backend 4cec3a0

PS: Current change being generaly healthy I don't mind it but I'm not very excited with promoting and encouraging support of multiple-imgui-context-each-in-their-own-backend-context. I think that feature is likely to be incompatible with multi-viewports (single imgui context + multiple backend windows) and I think instead we should aim at reworking this to let user register any existing window.