4 ms·

I have seen quite often 'immediate mode gui' on HN and elsewhere these days,I rarely do GUI myself, where are these im-gui's use cases? gaming only? or some emb

I have seen quite often 'immediate mode gui' on HN and elsewhere these days,I rarely do GUI myself, where are these im-gui's use cases? gaming only? or some embedded boards with limited resources can benefit to draw some pixels on a small LCD for a simple GUI(even that people are more likely use some light-weight x11 like libraries instead of im-gui library)? Other than game-development why is im-gui better than those normal widget kits we are relatively more familiar with: gtk, qt,etc)? or im-gui is specifically for gaming coding?

flohofwoe 5y ago
It's (more or less) just a different approach to describe a UI through code which does away with objects, event handlers or data binding. Very convenient for purely code driven UI development.
quotemstr 5y ago
Many people at a certain point in their careers become infatuated with the idea of making a "small", "simple", and "opinionated" component free from legacy "BS". They have the skill to implement the core of that component but lack the wisdom and humility to understand that the "BS" complexity exists for good reasons, that their "small" component is subject to those reasons, and that they haven't actually found a fundamentally better approach that avoids the "BS", but merely skipped the hard parts of software engineering. You just have to let people go through this phase. You should nod, smile, and compliment them on the economy of their vision. This phase hones skills people need for more serious endeavors. Butt God help you if you actually use one of these "small" systems in production!
- throwaway684936 5y ago
  Immediate mode is generally used for quick and dirty developer tools. It's rarely used for user-facing UI. You're free to waste your time carefully architecting an MVC application any time you want a few text boxes and sliders to fiddle with something. Microsoft, Google, Nvidia, Valve, Id, Blizzard, Ubisoft will continue to use immediate mode where they deem it useful, in spite of your advice.
- astrobe_ 5y ago
  Apparently you know the feeling when a competitor comes up and do 80% of what you're doing for half the cost (in dev time, memory weight, etc.). Hell, it still feels unfair even when it's a coworker who gets tasked with redoing (usually using some trendy new stuff) the system you've been maintaining for so long and know by heart, and that you've dreamed to rewrite for an equally long time. You comfort yourself by saying they will run into the same problems that just wait their time in a dark corners of software or hardware. But they generally are in a much better position, with their smaller and simpler software, to deal with it than with old software.
- AussieWog93 5y ago
  What your heuristic may be accurate in the general sense, it's absolutely not the case for ImGUIs. I've used the technology on a real commercial product before and it was vastly superior to the old way of doing things. The "BS" complexity of retained-mode GUIs, as you suggested, is not really BS but the logical result of using a client/server model. That said, for the average desktop application (where all necessary state is local to the user's own machine) this model really is a poor fit and ImGUIs shine. A lot of the evangelism comes from the fact that many more conservative devs still insist on using the more complex client/server retained-mode paradigm, even when immediate-mode is more suitable to the task at hand.
schaefer 5y ago
Immediate mode guis let you structure your code differently than traditional libraries. (gtk, etc.) It’s can be such a fast and light way to work. Get this thing done. And move on to the next thing. To me it’s just a valuable addition to our toolbox and our quest to use the right tool for the right job.
- lostdog 5y ago
  Yeah, but isn't there a CPU cost to having to run through your code on every frame?
- pjmlp 5y ago
  Retained UIs can be faster, because they only run the code related to the widget tree that is actually needed. It is like in games, everyone ends up implementing their own scene graph, while asserting they don't need the one offered by retained mode APIs.
throwaway684936 5y ago
Immediate mode GUIs can be used for almost anything that retained mode GUI toolkits (GTK, Qt) can be used for. It removes a lot of the overhead and boilerplate to speed up development.
Adverblessly 5y ago
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.
avodonosov 5y ago
The immediate mode gui is largely a myth, IMHO. The concept of gui fully controlled by program data works well for interfaces consisting of a single button. As soon as we have two buttons, each button has a position, and the positions is the data of the gui itself (retained data), not of the program. Imagine a multi-tab interface - which tab is currently active and has its controls drawn is the property of the gui (retained data), again. An action that can be invoked through a menu and can also be added to a toolbar. The toolbar can be expanded or collapsed. Again, that's data of the gui itself (of the view), not of the program (the model). The currently focused button should be highlighted somehow - the property of the gui again. Selected elements of a list (they should be highlighted). Expanded/collapsed state of a tree widget nodes. Scroll positions. So, the immediate mode guis are interesting and somewhat liberating because they demonstrate one can easily build simple ui without complex widget libs, but the results are limited, and very soon stop being really immediate mode. When evolving, they become reinvented wheels of retained mode guis.
- cyber_kinetist 5y ago
  All of these functionalities that you have described can b e easily implemented in an immediate-mode UI framework, and in my opinion much easily than retained-mode UI frameworks. (I know this because I have used Dear IMGUI extensively, and have done almost all of the things you’ve said). I think you’re arguing with some fundamental “philosophical” stance on what data should be owned by the user and what data should be owned by the GUI. But I feel that pragmatically immediate-mode GUIs are the most efficient at creating complex interfaces (like the ones you have described). The parts where IMGUi are lacking is in complex flexbox layouting, theming, and animations, which isn’t required in editor-like applications for professionals but might matter with end-user applications.
  - throwaway82652 5y ago
    >complex flexbox layouting, theming, and animations The only way to implement those things in an immediate mode framework is to cache a lot of state. I haven't found this to be any easier, once the layout becomes complex enough the amount of information that needs to be cached approaches what it would be in retained mode. Because of this I've also found the performance of immediate mode to be very bad. Especially when it involves: - large pieces of reflowing text (this means no text editors or word processors) - very large datasets in list/tree/column/grid widgets (this means no database editors or spreadsheets) - something like a flexbox, css grid or a constraint-solver based layout (this means no responsive layouts) These are all nice things that don't fit well with those patterns. Without any caching or keying it's functionally equivalent to having a React layout that diffs the entire tree before every redraw. The main use cases for immediate mode appears to only be quick prototyping, and making debugging tools for games and simulators. That's not bad by any means, but I've never seen one that is able to efficiently do complex layouts with large datasets.
AussieWog93 5y ago
>Other than game-development why is im-gui better than those normal widget kits we are relatively more familiar with: gtk, qt,etc)? I was tasked with using both types of frameworks back in my old job. ImGui eliminates entire classes of bugs related to state synchronisation, and was much easier to make performant because it was overall simpler[1]. It's also much simpler to customise, as widgets are nothing more than functions that draw graphics according to a couple of input variables. I think a lot of people get confused, as they think ImGuis mean redrawing every asset every frame and therefore performance should be bad. In practice, though, there are driver-side caches and it's absolutely excellent to both work with and use the results of. [1] While in theory retained-mode GUIs should be as performant as ImGuis or better, in practice it's much easier in retained-mode to accidentally perform an expensive action multiple times in a row in response to a single user interaction. Just tick "select all" on a WordPress page with 100+ elements and you'll see it immediately (well, immediately after several billion cycles have passed anyway!).

flohofwoe 5y ago

It's (more or less) just a different approach to describe a UI through code which does away with objects, event handlers or data binding. Very convenient for purely code driven UI development.

quotemstr 5y ago

Many people at a certain point in their careers become infatuated with the idea of making a "small", "simple", and "opinionated" component free from legacy "BS". They have the skill to implement the core of that component but lack the wisdom and humility to understand that the "BS" complexity exists for good reasons, that their "small" component is subject to those reasons, and that they haven't actually found a fundamentally better approach that avoids the "BS", but merely skipped the hard parts of software engineering. You just have to let people go through this phase. You should nod, smile, and compliment them on the economy of their vision. This phase hones skills people need for more serious endeavors. Butt God help you if you actually use one of these "small" systems in production!

throwaway684936 5y ago
Immediate mode is generally used for quick and dirty developer tools. It's rarely used for user-facing UI. You're free to waste your time carefully architecting an MVC application any time you want a few text boxes and sliders to fiddle with something. Microsoft, Google, Nvidia, Valve, Id, Blizzard, Ubisoft will continue to use immediate mode where they deem it useful, in spite of your advice.
astrobe_ 5y ago
Apparently you know the feeling when a competitor comes up and do 80% of what you're doing for half the cost (in dev time, memory weight, etc.). Hell, it still feels unfair even when it's a coworker who gets tasked with redoing (usually using some trendy new stuff) the system you've been maintaining for so long and know by heart, and that you've dreamed to rewrite for an equally long time. You comfort yourself by saying they will run into the same problems that just wait their time in a dark corners of software or hardware. But they generally are in a much better position, with their smaller and simpler software, to deal with it than with old software.
AussieWog93 5y ago
What your heuristic may be accurate in the general sense, it's absolutely not the case for ImGUIs. I've used the technology on a real commercial product before and it was vastly superior to the old way of doing things. The "BS" complexity of retained-mode GUIs, as you suggested, is not really BS but the logical result of using a client/server model. That said, for the average desktop application (where all necessary state is local to the user's own machine) this model really is a poor fit and ImGUIs shine. A lot of the evangelism comes from the fact that many more conservative devs still insist on using the more complex client/server retained-mode paradigm, even when immediate-mode is more suitable to the task at hand.

schaefer 5y ago

Immediate mode guis let you structure your code differently than traditional libraries. (gtk, etc.) It’s can be such a fast and light way to work. Get this thing done. And move on to the next thing. To me it’s just a valuable addition to our toolbox and our quest to use the right tool for the right job.

lostdog 5y ago
Yeah, but isn't there a CPU cost to having to run through your code on every frame?
pjmlp 5y ago
Retained UIs can be faster, because they only run the code related to the widget tree that is actually needed. It is like in games, everyone ends up implementing their own scene graph, while asserting they don't need the one offered by retained mode APIs.

throwaway684936 5y ago

Immediate mode GUIs can be used for almost anything that retained mode GUI toolkits (GTK, Qt) can be used for. It removes a lot of the overhead and boilerplate to speed up development.

Adverblessly 5y ago

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.

avodonosov 5y ago

The immediate mode gui is largely a myth, IMHO. The concept of gui fully controlled by program data works well for interfaces consisting of a single button. As soon as we have two buttons, each button has a position, and the positions is the data of the gui itself (retained data), not of the program. Imagine a multi-tab interface - which tab is currently active and has its controls drawn is the property of the gui (retained data), again. An action that can be invoked through a menu and can also be added to a toolbar. The toolbar can be expanded or collapsed. Again, that's data of the gui itself (of the view), not of the program (the model). The currently focused button should be highlighted somehow - the property of the gui again. Selected elements of a list (they should be highlighted). Expanded/collapsed state of a tree widget nodes. Scroll positions. So, the immediate mode guis are interesting and somewhat liberating because they demonstrate one can easily build simple ui without complex widget libs, but the results are limited, and very soon stop being really immediate mode. When evolving, they become reinvented wheels of retained mode guis.

cyber_kinetist 5y ago
All of these functionalities that you have described can b e easily implemented in an immediate-mode UI framework, and in my opinion much easily than retained-mode UI frameworks. (I know this because I have used Dear IMGUI extensively, and have done almost all of the things you’ve said). I think you’re arguing with some fundamental “philosophical” stance on what data should be owned by the user and what data should be owned by the GUI. But I feel that pragmatically immediate-mode GUIs are the most efficient at creating complex interfaces (like the ones you have described). The parts where IMGUi are lacking is in complex flexbox layouting, theming, and animations, which isn’t required in editor-like applications for professionals but might matter with end-user applications.
- throwaway82652 5y ago
  >complex flexbox layouting, theming, and animations The only way to implement those things in an immediate mode framework is to cache a lot of state. I haven't found this to be any easier, once the layout becomes complex enough the amount of information that needs to be cached approaches what it would be in retained mode. Because of this I've also found the performance of immediate mode to be very bad. Especially when it involves: - large pieces of reflowing text (this means no text editors or word processors) - very large datasets in list/tree/column/grid widgets (this means no database editors or spreadsheets) - something like a flexbox, css grid or a constraint-solver based layout (this means no responsive layouts) These are all nice things that don't fit well with those patterns. Without any caching or keying it's functionally equivalent to having a React layout that diffs the entire tree before every redraw. The main use cases for immediate mode appears to only be quick prototyping, and making debugging tools for games and simulators. That's not bad by any means, but I've never seen one that is able to efficiently do complex layouts with large datasets.

AussieWog93 5y ago

>Other than game-development why is im-gui better than those normal widget kits we are relatively more familiar with: gtk, qt,etc)? I was tasked with using both types of frameworks back in my old job. ImGui eliminates entire classes of bugs related to state synchronisation, and was much easier to make performant because it was overall simpler[1]. It's also much simpler to customise, as widgets are nothing more than functions that draw graphics according to a couple of input variables. I think a lot of people get confused, as they think ImGuis mean redrawing every asset every frame and therefore performance should be bad. In practice, though, there are driver-side caches and it's absolutely excellent to both work with and use the results of. [1] While in theory retained-mode GUIs should be as performant as ImGuis or better, in practice it's much easier in retained-mode to accidentally perform an expensive action multiple times in a row in response to a single user interaction. Just tick "select all" on a WordPress page with 100+ elements and you'll see it immediately (well, immediately after several billion cycles have passed anyway!).