3 ms·

I actually started tinkering with Dear Imgui, very cool library! From your experience, does this approach scale for complex apps with a lot of data updates, wit

I actually started tinkering with Dear Imgui, very cool library! From your experience, does this approach scale for complex apps with a lot of data updates, with dozens time series visualized, edited, etc., or am I overthinking?

joeld42 5y ago
It does, but you have to do a few extra things beyond what you'd do for the typical stuff like in-game editors and debug tools. - Data update are the best part -- there's no synchronization needed with an IMGUI approach because the "model" and "view" are the same thing. - adjust the event loop so it only redraws on changes (e.g. mousemovement) rather than every frame (unless you're drawing every frame anyways for a game) - IMGUIs can have trouble with very large lists -- imagine you have a tree view with 20k objects, you're going to process each one of them each time through the gui, even though most of them are outside the visible list. But it's hard to only draw the "visible" ones since you don't know the future (e.g. imagine iterating a list where some items are hidden). Usually this isn't a big deal to work around, just keep it in mind. - Biggest problem i've run into with IMGUI style is layout. Since you are processing widgets as you go, you can't adjust to future things. For simple layouts like stacked property sheets this is fine, but once you get beyond that it can be complicated. I'm playing with some ideas now where I use a constraint based layout to come up with "reference boxes" up front that then the IMGUI can use to layout but it's still a pretty open problem.
- syntheweave 5y ago
  When listed elements(including trees) are very large, there's a reasonable compromise pattern throughout UI in pagination. We've already found that infinite scroll isn't that desirable for productive UX because it eliminates any kind of landmarks, and tree views are the same way: so, my current belief on what to do is to default to expanding breadth-first to some limit, and then bias node expansion in places where the user has clicked, including some history so that the UI can present multiple leaf nodes simultaneously. You can imagine this as having cursors for each explored branch and viewing the area around the cursor, with "18,000 more items..." at the edges of the view. Re: the layout problem, it seems to be a factor in a lot of real-world apps(buildings, hardware design, etc.) and to the extent that it's "solved" by retained mode, it's a solution based on moving around the processing order so that you deal with a different set of constraint edge cases manually. As such I think it really is just a unsolved class of issues, which wasn't tackled before because it involved a degree of algorithmic complexity and resource use that wasn't on the table in the 1980's when the GUI was first widely adopted. So I think it's fine to explore having a whole algorithmic path and data structures dedicated to building the bounding targets for both collision and rendering - I have done similar when I've poked around at doing my own framework. That reflects the actual complexity of the solution, and it becomes especially apparent how deep you could go once you allow your targets to be arbitrary shapes with 2D transforms.
- scott01 5y ago
  Thanks for the insights! A related question, have you tried implementing “latent updates” of different IMGUI widgets based on whether their data was updated or not? I was kinda thinking how to avoid redrawing everything in a non-forms UI, like a node editor where each node is a graph, for example.
laserbeam 5y ago
Yes. The maintainer regularly posts screenshots of apps using dear imgui in the wild, and they are as complex as you can imagine. https://twitter.com/ocornut?s=21 https://twitter.com/ocornut?s=21

joeld42 5y ago

It does, but you have to do a few extra things beyond what you'd do for the typical stuff like in-game editors and debug tools. - Data update are the best part -- there's no synchronization needed with an IMGUI approach because the "model" and "view" are the same thing. - adjust the event loop so it only redraws on changes (e.g. mousemovement) rather than every frame (unless you're drawing every frame anyways for a game) - IMGUIs can have trouble with very large lists -- imagine you have a tree view with 20k objects, you're going to process each one of them each time through the gui, even though most of them are outside the visible list. But it's hard to only draw the "visible" ones since you don't know the future (e.g. imagine iterating a list where some items are hidden). Usually this isn't a big deal to work around, just keep it in mind. - Biggest problem i've run into with IMGUI style is layout. Since you are processing widgets as you go, you can't adjust to future things. For simple layouts like stacked property sheets this is fine, but once you get beyond that it can be complicated. I'm playing with some ideas now where I use a constraint based layout to come up with "reference boxes" up front that then the IMGUI can use to layout but it's still a pretty open problem.

syntheweave 5y ago
When listed elements(including trees) are very large, there's a reasonable compromise pattern throughout UI in pagination. We've already found that infinite scroll isn't that desirable for productive UX because it eliminates any kind of landmarks, and tree views are the same way: so, my current belief on what to do is to default to expanding breadth-first to some limit, and then bias node expansion in places where the user has clicked, including some history so that the UI can present multiple leaf nodes simultaneously. You can imagine this as having cursors for each explored branch and viewing the area around the cursor, with "18,000 more items..." at the edges of the view. Re: the layout problem, it seems to be a factor in a lot of real-world apps(buildings, hardware design, etc.) and to the extent that it's "solved" by retained mode, it's a solution based on moving around the processing order so that you deal with a different set of constraint edge cases manually. As such I think it really is just a unsolved class of issues, which wasn't tackled before because it involved a degree of algorithmic complexity and resource use that wasn't on the table in the 1980's when the GUI was first widely adopted. So I think it's fine to explore having a whole algorithmic path and data structures dedicated to building the bounding targets for both collision and rendering - I have done similar when I've poked around at doing my own framework. That reflects the actual complexity of the solution, and it becomes especially apparent how deep you could go once you allow your targets to be arbitrary shapes with 2D transforms.
scott01 5y ago
Thanks for the insights! A related question, have you tried implementing “latent updates” of different IMGUI widgets based on whether their data was updated or not? I was kinda thinking how to avoid redrawing everything in a non-forms UI, like a node editor where each node is a graph, for example.

laserbeam 5y ago

Yes. The maintainer regularly posts screenshots of apps using dear imgui in the wild, and they are as complex as you can imagine. https://twitter.com/ocornut?s=21 https://twitter.com/ocornut?s=21