Rendering multiple times per frame, at different resolutions.

[johanwendin]

Greetings!

I was toying with the idea to use dear imgui inside my game as well as for the editor UI (mostly for the excellent text-rendering as the rest is more easily done with sprites).

However, I'm using off-screen surfaces (FBO when using the OpenGL renderer f.e.) at a fixed low resolution in-game which is then scaled up to whatever the real resolution of the user's window is.

I could render it like normal, but then the pixel size wouldn't match (pixelated game with non-pixelated UI).

I could also just change the render function to use the FBO dimensions and render the UI before it's blitted to normal size - but that makes the editor UI pixelated as well.

Therefore, I'm looking for an easy way to render twice per frame. Once into the FBO (game UI at 240 pixel height mid frame) and once for the editor UI at the end (at f.e. my normal 1440 pixel height).

It's not necessary with input for the in-game UI (mouse, keyboard etc - that's handled separately) - so basically I'm looking for a way to reset the drawlists mid-frame. Calling NewFrame mid-frame resets the input handling for the editor UI, and I could re-arrange my code to re-send the input, but thought I'd ask if there's another way first. (might be easier to just extract the text-rendering/wrapping functions of dear imgui and turn it into a mini-DirectWrite for in-game use).

Thanks in advance,
Johan

[johanwendin]

This is possibly related to #545

"Render what we've got so far, with this flag set, then start fresh for later in the frame".

A BeginDraw/EndDraw with a flag passed on inside ImDrawData if you will.

[ocornut]

The problem is that ImGui carry and maintain state across frames when interacting with widgets. If you were to run two frames in a row with completely different sets of windows/widgets they would all have a lifetime of 1 frame from ImGui POV and that would create issues when interacting with them.

You could use a wide virtual desktop (increase io.DisplaySize) and dispatch content one side or another but that's generally awkward if one side is much smaller than the other.

While rendering to windows, you could tag a specify ImDrawList to be rendered in a different target. If your window is flagged with the NoInput flag it won't interfer with other windows.

The most natural solution would probably to use multiple imgui contexts (see, e.g. #269 )

(might be easier to just extract the text-rendering/wrapping functions of dear imgui and turn it into a mini-DirectWrite for in-game use).

Or you can also create separate ImDrawList instances, write contents to them and render them directly with your rendering code. 99% of ImDrawList code is independant from ImGui but not all of it, it still expect the same atlas and "current font" state of ImGui but that shouldn't be a problem.

[johanwendin]

Thank you, I'll look into it! :)