3 ms·

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 m

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...
theonething 5y ago
sounds like html over the wire in the web world. State only resides on the backend. I think it's a good direction.

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...

theonething 5y ago

sounds like html over the wire in the web world. State only resides on the backend. I think it's a good direction.