Is it possible to round robin contexts?

[w103csh]

Version/Branch of Dear ImGui:

current

Back-ends:

custom

Compiler, OS:

ps5

Full config/build information:

No response

Details:

Is it possible to round robin contexts?

Hello. I was curious if it was possible to round robin contexts. So on frame N I use context N, and on frame N+1 I want to use context N+1, etc. I could then double/triple buffer the contexts. This doesn't seem to work because some of the IO information appears to get cached (maybe other things as well). I thought maybe there was a way to forward just the IO information from context N to N+1 somehow, but I can't find it.

Our use case is very similar to what https://github.com/ocornut/imgui_club/tree/main/imgui_multicontext_compositor tries to achieve, but we don't have hard sync points every frame where we can call ImGuiMultiContextCompositor_PreNewFrameUpdateAll and ImGuiMultiContextCompositor_PostEndFrameUpdateAll. We have an update and render domain but we overlay the domains.

Thanks for the great library!

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

[w103csh]

Here is an example of the way we overlay frames, and where I'd imagine we'd use the multi-context compositor extension (I did not add the post render update all markers but hopefully you get the idea).

I believe that if there was a way to forward the cached state from context N to context N+1 then this would all work nicely. Or maybe there is some other existing part of the api that makes this type of thing possible.

[ocornut]

Hello. I was curious if it was possible to round robin contexts. So on frame N I use context N, and on frame N+1 I want to use context N+1, etc. I could then double/triple buffer the contexts.

No it is not possible. Regardless of IO, temporal coherency is essential to how Dear ImGui works.

But this feels like a XY Problem. I don't think you need to round-robin contexts. It seems like want a single context but need to take a snapshot of the ImDrawData at the end of Update N in order for Rendering N to draw it safely?

In which case your problem would be the same as #1860, #3515.

Can you try my suggested code in #1860 (comment) ?

I would be interested in promoting this code to a mini-lib in imgui_club/ if this is confirmed to work for you. Assuming I understood your problem well.

[w103csh]

Hey. Thanks for the response.

So I already setup the update context to copy the draw data and forward it to the render domain, and then let the render domain render both its context and the update domain's context. I was trying to think of a way to also use the multi-context compositor with this setup. Its cool if this type of thing isn't possible. I was just curious if there was something I could use that I was missing.

I'll dig through that code you shared and make sure I'm doing something similar.

Again, thanks for the great api!!!

[ocornut]

So I already setup the update context to copy the draw data and forward it to the render domain

Note that my code linked above is using buffer swap to avoid constant copy.

and then let the render domain render both its context and the update domain's context. I was trying to think of a way to also use the multi-context compositor with this setup. Its cool if this type of thing isn't possible. I was just curious if there was something I could use that I was missing.

You should be able to combine both multi-context compositor and that ImDrawDataSnapshot logic indeed.

AFAIK they are orthogonal enough that one doesn't need to know/care about the other.

My suggested code for ImDrawDataSnapshot may not scale/work with multi-viewports when using the RenderPlatformWindowsDefault() helper but it's easier to avoid it.

I'll dig through that code you shared and make sure I'm doing something similar.

If you want to help I would appreciate if you can aim to use exactly the code as provided, or share fixes/suggestion if needed. The goal being to be able to share that code with others, but I can't do it until I've got some confirmation it is good enough.

[w103csh]

Okay. I'll attempt to swap out my code with yours, and let you know how it goes. We have a bunch of different memory allocators that are better to use with certain domains, so we might not keep your code exactly, but I can add a toggle that uses your code verbatim and let it soak.

We're just starting to integrate the library into our engine so it might take a bit to get it in. I'll try to keep you updated.

[ocornut]

Right, even though everything will go through our shared allocator (which you can override with SetAllocatorFunctions()) i understand that in the context of passing things from one domain to another it might be trickier to reuse that code as-is.
A mere signal that the code is functional enough and I may be tempted to simply release it as it.
Don't hesitate to reach out if you have more questions.