4 ms·

ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Be

ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.

gambiting 6y ago
Well yes, sorry, I misspoke.
flohofwoe 6y ago
This point is so important that it bears repeating: only the programming model is "immediate", not the implementation under the hood. Dear ImGui keeps (internal) state around between frames, maybe not as much as other UI frameworks, but it does. Especially the rendering isn't "immediate mode", the UI isn't rendered while running the code that's building the API. Instead Dear ImGui builds a "deferred mode" rendering command list which is actually very efficient in terms of required draw calls. The main difference to traditional UI frameworks is that there are no different code paths for UI creation, UI updating, and handling input. Instead all those things are happening in the same sequential code flow.
- formerly_proven 6y ago
  Rather important is the state ImGui keeps around is independent of the number of widgets. (Imgui's inter-frame state is essentially a list of top-level windows, a list of pressed buttons and the ID of the active/focused widget -- that's enough). This makes ImGui perfect for inserting it into the traversal of complex data structures and ensures perfect synchrony between UI and data. This is an area were classic GUI tooling often struggles; sure it's totally possible to do with e.g. Qt but making a scene graph accessible as a Qt model likely amounts to a few thousand lines of code, but is comparatively trivial with tightly-coupled ImGui code. Embedding GUIs into a 3D viewport is also something these frameworks aren't generally designed to do, but is the easiest way to do it with ImGui. That being said, real GUI frameworks like Qt are a much better choice for 97 % of "end-user tools", because they have all the bells and whistles you do, in fact, want to have in a desktop application (RAD tools, proper layout system, proper menu/action system, accessibility integration, state inspection etc.)
  - flohofwoe 6y ago
    > ... because they have all the bells and whistles... None of that is incompatible with the immediate-mode-UI philosophy though, it's just that this specific UI toolkit (Dear ImGui) is coming from a direction where those things haven't been that important.
    - formerly_proven 6y ago
      Oh but it is. A proper menu/action system requires the toolkit to retain all menus and actions; ImGui doesn't do that (and shouldn't, considering all the places you can put a menu), it also requires layered event handling, which ImGui doesn't want to have. Accessibility requires a retained widget tree, which ImGui explicitly doesn't want. Layouts are incompatible with the current immediate mode API (but could be implemented in an immediate mode API given a legion of lambdas), because the size of widgets depends on the size and possibly contents of other widgets; for ImGui this is all fixed when you call Button(), which immediately calculates all vertices and adds them to the drawlist (that's the retained part in ImGui). There are probably many more points.
      - flohofwoe 6y ago
        I still see those mostly as implementation details of this specific library (Dear ImGui), not as problems of the general idea of UIs that are described through an immediate mode API. I'm sure I'm missing a few important details, but what's preventing another library to make the internals more retained while keeping the illusion of an immediate mode UI on the user side of the API (which is the important part). The internal implementation may be much more complicated than what Dear ImGui does, maybe it's necessary to run multiple passes over the UI description to create the layout, etc... but that might be worth it if the programming model remains as simple as it is now.

gambiting 6y ago

Well yes, sorry, I misspoke.

flohofwoe 6y ago

This point is so important that it bears repeating: only the programming model is "immediate", not the implementation under the hood. Dear ImGui keeps (internal) state around between frames, maybe not as much as other UI frameworks, but it does. Especially the rendering isn't "immediate mode", the UI isn't rendered while running the code that's building the API. Instead Dear ImGui builds a "deferred mode" rendering command list which is actually very efficient in terms of required draw calls. The main difference to traditional UI frameworks is that there are no different code paths for UI creation, UI updating, and handling input. Instead all those things are happening in the same sequential code flow.

formerly_proven 6y ago
Rather important is the state ImGui keeps around is independent of the number of widgets. (Imgui's inter-frame state is essentially a list of top-level windows, a list of pressed buttons and the ID of the active/focused widget -- that's enough). This makes ImGui perfect for inserting it into the traversal of complex data structures and ensures perfect synchrony between UI and data. This is an area were classic GUI tooling often struggles; sure it's totally possible to do with e.g. Qt but making a scene graph accessible as a Qt model likely amounts to a few thousand lines of code, but is comparatively trivial with tightly-coupled ImGui code. Embedding GUIs into a 3D viewport is also something these frameworks aren't generally designed to do, but is the easiest way to do it with ImGui. That being said, real GUI frameworks like Qt are a much better choice for 97 % of "end-user tools", because they have all the bells and whistles you do, in fact, want to have in a desktop application (RAD tools, proper layout system, proper menu/action system, accessibility integration, state inspection etc.)
- flohofwoe 6y ago
  > ... because they have all the bells and whistles... None of that is incompatible with the immediate-mode-UI philosophy though, it's just that this specific UI toolkit (Dear ImGui) is coming from a direction where those things haven't been that important.
  - formerly_proven 6y ago
    Oh but it is. A proper menu/action system requires the toolkit to retain all menus and actions; ImGui doesn't do that (and shouldn't, considering all the places you can put a menu), it also requires layered event handling, which ImGui doesn't want to have. Accessibility requires a retained widget tree, which ImGui explicitly doesn't want. Layouts are incompatible with the current immediate mode API (but could be implemented in an immediate mode API given a legion of lambdas), because the size of widgets depends on the size and possibly contents of other widgets; for ImGui this is all fixed when you call Button(), which immediately calculates all vertices and adds them to the drawlist (that's the retained part in ImGui). There are probably many more points.
    - flohofwoe 6y ago
      I still see those mostly as implementation details of this specific library (Dear ImGui), not as problems of the general idea of UIs that are described through an immediate mode API. I'm sure I'm missing a few important details, but what's preventing another library to make the internals more retained while keeping the illusion of an immediate mode UI on the user side of the API (which is the important part). The internal implementation may be much more complicated than what Dear ImGui does, maybe it's necessary to run multiple passes over the UI description to create the layout, etc... but that might be worth it if the programming model remains as simple as it is now.