sammyfreg
Supporting multiple imgui contexts in the same app
Hello,
In our app, we have multiple imgui contexts at the same time, because we have separate game and rendering threads which can call imgui. When using NetImgui, the result is that only the commands sent to one of the contexts are shown in the remote viewer (the context which was current when NetImgui::Connect* was called, since that's the context to which the hooks were added).
Is there a way you had envisioned supporting this? I can tell you what I have, but I'm not sure that's how it should work, ideally.
So what I did was to call NetImgui::Connect* for both contexts. This gives me two client windows in the remote viewer, which is not ideal. So I made some changes to the remote viewer so that when the connection client name (client.mInfoName) is the same for two connections, they both use the same client instance (and then I had to make changes so that a single client can have multiple imgui draw data, one for each connection). And finally, when rendering the imgui draw data, I made it clear the texture only for the first one. These changes have no effect if there is only one connection per client, of course.
If you're interested I can send a patch with these changes. But I'd be interested to know what the ideal solution would look like in your opinion.
My first question is, are the 2 contexts supposed to be visible at the same time?
If both are active, it means that the same input is sent to both? And since they each generates their own draws, one context is always rendered in top of the other one? If this is the case, I'd have to give it some thoughts.
If it's the alternative of only having 1 context active at a time, with a way to switch between them, then this can be handled without changes. In fact, the Unreal ImGui plugin does this, it has multiple contexts and when connected with NetImgui, allows users to chose which context should be send for remote rendering.
Both contexts are active at the same time. Yes, inputs are sent to both. For the rendering, I'm not sure, because I noticed that windows don't overlap the same way in our engine as they do in the remote viewer, so there must be some ordering issue. I'll investigate more on Monday. My implementation is not perfect for sure, but I did it as a starting point to see if it was possible.
Hmmm, that's pretty unusual, having 2 contexts processing the same inputs and rendering to the same output.
How does it even handle having a valid window around same location of both context, to determine who gets the mouse click input?