[weinzierl]

> A few problems with this GUI style are:

> You have to write lots of code to manage the the creation and destruction of GUI objects. [..]

> The creation and destruction problem leads to slow unresponsive UIs [..]

> You have to marshal your data into and out of the widgets. [..]

My biggest pain point with the retained mode GUIs I worked with was none of the issues mentioned above. It was always the centralized GUI thread and the consequential synchronization complications. I don't know if this is an inherent problem of retained mode GUI frameworks and if there are some that don't force all widgets into a single thread. If not, this alone is a reason to for me to find immediate mode interesting.

[overgard]

Immediate mode, if anything, makes this harder. (You absolutely have to run the GUI on one thread, for instance). Really though you can get around that on either of them by spawning a worker thread/coroutine/etc. on button clicks and so on.

[weinzierl]

The real problems start, when the worker thread needs to update the GUI, for example to advance a progress bar. With the frameworks I know I have to build a communication channel between the threads and tell the GUI thread to show and update the progress bar.

My hope was that with an immediate mode framework I could just show a progress bar on top of the existing GUI right from the worker thread. I don't know enough about immediate mode to say if this is really possible. It would simplify a lot of my code though.