4 ms·

Does anyone care to explain what immediate mode means?

deleted 5y ago
[deleted]
delian66 5y ago
See https://en.wikipedia.org/wiki/Immediate_mode_(computer_graphics) https://en.wikipedia.org/wiki/Immediate_mode_(computer_graph... , and https://en.wikipedia.org/wiki/Immediate_mode_GUI https://en.wikipedia.org/wiki/Immediate_mode_GUI . TLDR: instead of declaring your GUI objects/components ahead of time, and letting a framework render the prepared scene graph (while calling you back when there are user triggered state changes), you just draw the GUI objects yourself in your main loop, just like you draw all your other objects (backgrounds, sprites, models etc).
modeless 5y ago
Immediate mode is a style of API where important state is kept in user code instead of being retained inside the API implementation. For example, an immediate mode GUI checkbox implementation does not store a boolean value determining whether the checkbox is checked. Instead, user code passes that information as a function parameter whenever the UI needs to be drawn. Even the fact that a checkbox exists on screen is not stored in the GUI library. The checkbox is simply drawn when user code requests it each frame. Couterintuitively this is often less complicated than the traditional "retained mode" style of GUI libraries because there is no duplication of state. That means no setup or teardown of widget object trees, no syncing of state between GUI objects and application code, no hooking up or removing event handlers, no "data binding", etc. The structure and function of your UI is naturally expressed in the code of the functions that draw it, instead of in ephemeral and opaque object trees that only exist in RAM after they're constructed at runtime. You retain control over the event loop and you define the order in which everything happens rather than receiving callbacks in some uncertain order from someone else's event dispatching code. Crucially, "immediate mode" is a statement about the interface of the library, not the internals. Common objections of the form "immediate mode GUIs can't support X" or "immediate mode GUIs are inefficient because Y" are generally false and based on a misconception that immediate mode GUIs are forbidden from retaining any internal state at all. It is perfectly normal for an immediate mode library to retain various types of internal state for efficiency or other reasons, and this is fine as long as the state stored in user code remains the source of truth. This can even go as far as internally constructing a whole retained widget tree and maintaining it via React-like tree diffing.
- ocornut 5y ago
  I picked your write-up on that unstructured attempt of making a page of definitions: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradigm https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi... Thanks!
  - modeless 5y ago
    Cool! Feel free to use it and modify it however you want if that would be useful, no attribution required.
- lolinder 5y ago
  Jetpack Compose on Android has an API exactly like you describe, but I've never heard it described as an immediate-mode GUI. Is it one, or is there something else that makes a GUI toolkit immediate-mode?
  - modeless 5y ago
    Jetpack Compose is very interesting, but I don't think it's exactly what I described. It explicitly retains a lot of state including a widget tree and event handlers. Although the state is opaque because there is no DOM-like API to inspect it, the user is still required to reason about the retained state and know exactly when and which parts should be invalidated. It provides a lot of "convenience" features for the user to annotate and wrap state which is expected to change so that invalidation can happen semi-automatically. But that results in a lot of rules you must follow which can't be automatically checked or enforced, which ends up being rather complex I think: https://developer.android.com/jetpack/compose/state https://developer.android.com/jetpack/compose/state and https://developer.android.com/jetpack/compose/side-effects https://developer.android.com/jetpack/compose/side-effects Here's a checkbox in Jetpack Compose with the required state annotation and event handling stuff, which if forgotten or done incorrectly will make the checkbox silently malfunction: val checkedState = remember { mutableStateOf(true) } Checkbox( checked = checkedState.value, onCheckedChange = { checkedState.value = it } ) And here's a checkbox in Dear Imgui which just uses a plain bool and no event handlers (also note that this includes a clickable text label which would require additional event handlers with Compose): static bool foo = true; // could be any bool in the application, nothing special about this one ImGui::Checkbox("Foo enabled", &foo) Here's a great example of how the retained state in Jetpack Compose can confuse people: https://stackoverflow.com/questions/70040541/jetpack-compose-checkbox-not-showing-changed-state https://stackoverflow.com/questions/70040541/jetpack-compose...
panzerboiler 5y ago
The best explanation is probably the one by Casey Muratori (https://caseymuratori.com/blog_0001 https://caseymuratori.com/blog_0001). He devised the technique and conied the term in 2002.
- ahefner 5y ago
  Can't imagine he was the first person to use this technique. I'd assume any game written from the point where it was reasonable to continually redraw the screen instead of using incremental repainting would've used such a technique, because it's simply the easiest way to implement random ad-hoc GUIs if you don't have a widget toolkit underneath you (and possibly even if you do).
  - panzerboiler 5y ago
    Probably. I was using a similar technique in the late 80s in turbo pascal. Casey has the merit to have given it a name and make a video about it.

deleted 5y ago

[deleted]

See https://en.wikipedia.org/wiki/Immediate_mode_(computer_graphics) https://en.wikipedia.org/wiki/Immediate_mode_(computer_graph... , and https://en.wikipedia.org/wiki/Immediate_mode_GUI https://en.wikipedia.org/wiki/Immediate_mode_GUI . TLDR: instead of declaring your GUI objects/components ahead of time, and letting a framework render the prepared scene graph (while calling you back when there are user triggered state changes), you just draw the GUI objects yourself in your main loop, just like you draw all your other objects (backgrounds, sprites, models etc).

modeless 5y ago

Immediate mode is a style of API where important state is kept in user code instead of being retained inside the API implementation. For example, an immediate mode GUI checkbox implementation does not store a boolean value determining whether the checkbox is checked. Instead, user code passes that information as a function parameter whenever the UI needs to be drawn. Even the fact that a checkbox exists on screen is not stored in the GUI library. The checkbox is simply drawn when user code requests it each frame. Couterintuitively this is often less complicated than the traditional "retained mode" style of GUI libraries because there is no duplication of state. That means no setup or teardown of widget object trees, no syncing of state between GUI objects and application code, no hooking up or removing event handlers, no "data binding", etc. The structure and function of your UI is naturally expressed in the code of the functions that draw it, instead of in ephemeral and opaque object trees that only exist in RAM after they're constructed at runtime. You retain control over the event loop and you define the order in which everything happens rather than receiving callbacks in some uncertain order from someone else's event dispatching code. Crucially, "immediate mode" is a statement about the interface of the library, not the internals. Common objections of the form "immediate mode GUIs can't support X" or "immediate mode GUIs are inefficient because Y" are generally false and based on a misconception that immediate mode GUIs are forbidden from retaining any internal state at all. It is perfectly normal for an immediate mode library to retain various types of internal state for efficiency or other reasons, and this is fine as long as the state stored in user code remains the source of truth. This can even go as far as internally constructing a whole retained widget tree and maintaining it via React-like tree diffing.

ocornut 5y ago
I picked your write-up on that unstructured attempt of making a page of definitions: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradigm https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi... Thanks!
- modeless 5y ago
  Cool! Feel free to use it and modify it however you want if that would be useful, no attribution required.
lolinder 5y ago
Jetpack Compose on Android has an API exactly like you describe, but I've never heard it described as an immediate-mode GUI. Is it one, or is there something else that makes a GUI toolkit immediate-mode?
- modeless 5y ago
  Jetpack Compose is very interesting, but I don't think it's exactly what I described. It explicitly retains a lot of state including a widget tree and event handlers. Although the state is opaque because there is no DOM-like API to inspect it, the user is still required to reason about the retained state and know exactly when and which parts should be invalidated. It provides a lot of "convenience" features for the user to annotate and wrap state which is expected to change so that invalidation can happen semi-automatically. But that results in a lot of rules you must follow which can't be automatically checked or enforced, which ends up being rather complex I think: https://developer.android.com/jetpack/compose/state https://developer.android.com/jetpack/compose/state and https://developer.android.com/jetpack/compose/side-effects https://developer.android.com/jetpack/compose/side-effects Here's a checkbox in Jetpack Compose with the required state annotation and event handling stuff, which if forgotten or done incorrectly will make the checkbox silently malfunction: val checkedState = remember { mutableStateOf(true) } Checkbox( checked = checkedState.value, onCheckedChange = { checkedState.value = it } ) And here's a checkbox in Dear Imgui which just uses a plain bool and no event handlers (also note that this includes a clickable text label which would require additional event handlers with Compose): static bool foo = true; // could be any bool in the application, nothing special about this one ImGui::Checkbox("Foo enabled", &foo) Here's a great example of how the retained state in Jetpack Compose can confuse people: https://stackoverflow.com/questions/70040541/jetpack-compose-checkbox-not-showing-changed-state https://stackoverflow.com/questions/70040541/jetpack-compose...

panzerboiler 5y ago

The best explanation is probably the one by Casey Muratori (https://caseymuratori.com/blog_0001 https://caseymuratori.com/blog_0001). He devised the technique and conied the term in 2002.

ahefner 5y ago
Can't imagine he was the first person to use this technique. I'd assume any game written from the point where it was reasonable to continually redraw the screen instead of using incremental repainting would've used such a technique, because it's simply the easiest way to implement random ad-hoc GUIs if you don't have a widget toolkit underneath you (and possibly even if you do).
- panzerboiler 5y ago
  Probably. I was using a similar technique in the late 80s in turbo pascal. Casey has the merit to have given it a name and make a video about it.