4 ms·

IMO The main benefit of immediate mode GUI is that (unlike "normal widget kits"), the data required to "drive" the widgets is not actually owned by the widgets

IMO The main benefit of immediate mode GUI is that (unlike "normal widget kits"), the data required to "drive" the widgets is not actually owned by the widgets themselves, making widgets controlled directly by the "program's" data. You make some sort of change to the program's data and it is immediately reflected on the screen. This is as opposed to the "normal widget kits" where you need some "glue" to reflect those changes for example maybe you need to let the widget know its contents were updated and it needs to redraw or redo its layout. This makes it easier to create certain types of UIs where the main interaction is to modify some data structure directly, which is how many simple tools behave.

gmueckl 5y ago
The unfortute truth to these toolkits is that they need to keep a ton of shadow state internally and diff that to the data coming in with each new frame. The most trivial example would be a button. The user redeclares this button each frame as if it was new, but the UI must unify that to a single persistent button instance to get the stateful button behavior right. Every interactive control needs similar logic. In essence you trade tailor-made, performant UI update code with an implicit, complicated and expensive semi-"transparent" generic update logic. It works for simple UI patterns with not too much data in the controls, but anything more heavy will r7n into problems.
- AussieWog93 5y ago
  That's not at all true, at least for Dear ImGui. I reimplemented the text rendering in it at one stage (we needed to support arbitrary unicode strings, specifically file names with CJK characters), drilling all the way down to individual OpenGL calls to get it running [1]. Apart from any driver-level caches, there really is no UI state. [1] For what it's worth, this was an easier undertaking than simply recompiling Qt.
  - gmueckl 5y ago
    What you're saying is copmpletely wrong. ImGUI is transparently creating structs with internal widget state for every slightly more complex widget on the screen. Look at the state structs in imgui_internal.h to get an idea of what I'm talking about, e.g. ImGuiInputTextState or the huge ImGuiWindow structs. The apparent statelessness of immediate mode GUIs is an illusion that is produced by an extra layer of internal logic that manages that state.
    - AussieWog93 5y ago
      ImGuiWindow is an exception to the rule in that it basically serves as a canvas for other widgets to be drawn on. Regarding complex widgets like TextInput or Tables having state, I'm completely OK with that. The problem with state in a retained-mode GUI is that it's stored in two places and can easily fall out of sync/create performance-related footguns/create unnecessary work building widgets. Whether or not they're "pure" immediate mode is not the point.

gmueckl 5y ago

The unfortute truth to these toolkits is that they need to keep a ton of shadow state internally and diff that to the data coming in with each new frame. The most trivial example would be a button. The user redeclares this button each frame as if it was new, but the UI must unify that to a single persistent button instance to get the stateful button behavior right. Every interactive control needs similar logic. In essence you trade tailor-made, performant UI update code with an implicit, complicated and expensive semi-"transparent" generic update logic. It works for simple UI patterns with not too much data in the controls, but anything more heavy will r7n into problems.

AussieWog93 5y ago
That's not at all true, at least for Dear ImGui. I reimplemented the text rendering in it at one stage (we needed to support arbitrary unicode strings, specifically file names with CJK characters), drilling all the way down to individual OpenGL calls to get it running [1]. Apart from any driver-level caches, there really is no UI state. [1] For what it's worth, this was an easier undertaking than simply recompiling Qt.
- gmueckl 5y ago
  What you're saying is copmpletely wrong. ImGUI is transparently creating structs with internal widget state for every slightly more complex widget on the screen. Look at the state structs in imgui_internal.h to get an idea of what I'm talking about, e.g. ImGuiInputTextState or the huge ImGuiWindow structs. The apparent statelessness of immediate mode GUIs is an illusion that is produced by an extra layer of internal logic that manages that state.
  - AussieWog93 5y ago
    ImGuiWindow is an exception to the rule in that it basically serves as a canvas for other widgets to be drawn on. Regarding complex widgets like TextInput or Tables having state, I'm completely OK with that. The problem with state in a retained-mode GUI is that it's stored in two places and can easily fall out of sync/create performance-related footguns/create unnecessary work building widgets. Whether or not they're "pure" immediate mode is not the point.