Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heavy OpenGL renderer and ImGui refresh #4592

Closed
vtushevskiy opened this issue Sep 28, 2021 · 4 comments
Closed

Heavy OpenGL renderer and ImGui refresh #4592

vtushevskiy opened this issue Sep 28, 2021 · 4 comments

Comments

@vtushevskiy
Copy link

vtushevskiy commented Sep 28, 2021

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?

@meshula
Copy link

meshula commented Sep 28, 2021

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.

@ocornut
Copy link
Owner

ocornut commented Sep 29, 2021

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.

@vtushevskiy
Copy link
Author

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

@ocornut ocornut added the opengl label May 25, 2023
@ocornut
Copy link
Owner

ocornut commented May 25, 2023

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.

@ocornut ocornut closed this as completed May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants