Comment by tarnith

> What if something is costly, that you need to compute dynamically, but not often, makes it into the frame? Do you separately now create a state flag for that one render object?

The point of immediate mode UIs is not necessarily that there is no state specific to the UI, but rather that the state is owned by user code. You can (and, in these more complex cases, should) retain state between frames. The main difference is that the state is still managed by your code, rather than the UI system ("library", whatever).

Immediate mode UI optimizes for the worst case. That is the case you care about most for real time applications.

Retained mode is more optimal when not much changes but if a lot of stuff changes at once it can be worse. So for real time applications like your audio example or games you want immediate mode. Retained mode is better for saving battery though or can be.

> What about when you're embedding your GUI into an existing application? or for use on an already taxed system?

You should check out the gamedev scene. It's soft real-time, and yet dearIMGUI is the choice for tooling. Immediate-mode is an API-design, not the implementation details. All Immediate-mode GUIs retain data some data, and for that reason they each have their own APIs for retaining data in various capacities. Usually something really simple like hashing and component-local state.

> This works for simple apps, utilities, and demos/mvps. Not great for actual applications.

Respectfully, I don't think you're informed on this. Probably the most responsive debugger out there is RAD Debugger and it's built with an IMGUI.

For interest sake, have a look at the flutter engine. It does this kind of diff on each build (meaning, each time the ui tree gets modified & triggers a rebuild); they split their objects into stateful & stateless, and then in your own code you have to make sure to not unnecessarily trigger rebuilds for expensive objects. So it kinda force you to think & separate cheap & expensive ui objects.

> Do you separately now create a state flag for that one render object?

That can be a reasonable choice sometimes. Note that the point is that you introduce state where necessary, rather than stateful UI being the default as with retained mode.

> What about when you're embedding your GUI into an existing application? or for use on an already taxed system? (Audio plugins come to mind)

I've used ImGui in exactly these kinds of projects. Game engines already render graphics, so it is just part of the same pipeline. Rendering the gui is instant, how many fps you want to render is up to you.