ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Heavy OpenGL renderer and ImGui refresh

vtushevskiy opened this issue · comments

I have heavy OpenGL renderer, in some cases it may render 1-2 frames per second or even less. With that usage the interface of ImGui is not responsive because it is refreshing with same speed as this heavy renderer. Basically it is almost impossible to use sliders/buttons etc during the render process.
Question: is there some way how to refresh ImGui interface more frequently than my background rendered?
I think multithreading with two threads with two OpenGL contexts would work here: first thread and context for ImGui UI, it is updating like 60 frames per second; second thread/context is heavy renderer: it is rendering few frames per second and when frame is done it is updating some flag and first thread/context checking this flag in the loop may use resulting texture to update background image in main window.
Do you have any ideas/examles/cases how to do it in some elegant way, if it is even possible?

What you want to do is OpenGL context sharing. You need to create a second rendering context, for an offscreen buffer. You can see how GLFW handles it here - https://www.glfw.org/docs/3.0/context.html - every GL wrapper handles it differently unfortunately. You can render, on a thread to the offscreen buffer. You need to double buffer the offscreen buffer, and use some kind of threadsafe interlock to swap the offscreen buffer and let your Dear ImGui thread know that a new offscreen buffer is ready to draw on a quad.

Hopefully this gives you enough clues on the topics you need to research.

commented

As a side note, the ways inputs are processed by default makes user interactions particularly painful at low FPS (e.g. #2787). We've been working with thedmd on formalizing the input queue and integrating it as part of dear imgui so it should arrive within a few months. That change will make interactions more viable at "reasonably low" FPS (e.g. 5-15 FPS). But at 1-2 FPS the input queue won't be good enough.

You'll indeed need to multi-thread your UI/imgui code there.

Thanks for answer!
Are there any known examples of multithreading implementation of glfw+imgui?

commented

Are there any known examples of multithreading implementation of glfw+imgui?

Sorry about not answering this earlier.
It's not much of a imgui specific issue, rather a multithreading OpenGL issue.
I believe Meshula's answer #4592 (comment) gives outline of what you need to do and there must be good reference available elsewhere, but it's generally out of scope of Dear ImGui. Probably you've already implemented it by now. I'll close this issue.

As a side note, the ways inputs are processed by default makes user interactions particularly painful at low FPS (e.g. #2787). We've been working with thedmd on formalizing the input queue

FYI that bit has been solved in 1.87.