imports/imgui
1
0
Fork 0
mirror of https://github.com/ocornut/imgui.git synced 2026-03-27 23:37:03 -05:00
Code Issues Packages Projects Releases Wiki Activity

Updated About the IMGUI paradigm (markdown)

omar
2024-09-08 18:49:28 +02:00
parent 0db00a798d
commit 8449109121
1 changed files with 9 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
About-the-IMGUI-paradigm.md

@@ -4,11 +4,12 @@ THIS IS WIP/DRAFT / [Discuss this article](https://github.com/ocornut/imgui/issu
**This is an attempt at explaining what the IMGUI paradigm stands for, and what it could be**.
Please note the [References](#references) section where other articles have been written about this.
Please note the [References](#references) section where several good articles have been written about this topic.
Proponent of the IMGUI paradigm have noticed that it was widely misunderstood, over and over.
As of ~~Feb 2021~~ January 2024, even the [IMGUI Wikipedia page](https://en.wikipedia.org/wiki/Immediate_mode_GUI) is **COMPLETELY** off the mark and incorrect. There are reasons for that:
- the acronym is misleading (read below).
As of ~~Feb 2021~~ January 2024, even the [IMGUI Wikipedia page](https://en.wikipedia.org/wiki/Immediate_mode_GUI) is completely off the mark and incorrect. (As of August 2024 the page seemingly have been nuked).
There are reasons for that:
- the acronym can be misleading (read below).
- people didn't do a good enough job explaining or documenting what IMGUI means?
- they are different interpretation of what IMGUI means?
- many popular IMGUI implementation have made similar design choices, making it more confusing what is actually the soul and backbone of the IMGUI paradigm vs a set of implementation choices.
@@ -97,14 +98,14 @@ _"I’ve also seen lots of people getting into arguments about immediate-mode vs
Casey's work on formulating and popularizing research on this topic has been pivotal and invaluable. His video and the forums that followed helped people gather around the concept and talk about it. Archive.org has a [2007 Mirror of Molly Rocket's IMGUI forums](https://web.archive.org/web/20070824203105/http://www.mollyrocket.com/forums/viewforum.php?f=10&sid=9680eeedbe87034741d936cbfe319f57), including [first notable post by Casey on 2005-07-05](https://web.archive.org/web/20070824213736/http://www.mollyrocket.com/forums/viewtopic.php?t=134&start=0&sid=cb913629aa8310947c0476848a8824dd). Unfortunately the [2013 Mirror of Molly Rocket's IMGUI forums](https://web.archive.org/web/20131221233224/http://mollyrocket.com/forums/viewforum.php?f=10&sid=b7ce0b0de4493f63edd88d13c99501a9) has index but no actual posts.
Sean Barrett (@nothings) contributed to popularizing the IMGUI paradigm by publishing [an article in the September 2005 issue of Game Developer Magazine](https://archive.org/details/GDM_September_2005) (Page 34) and [accompanying sample code](http://silverspaceship.com/inner/imgui).
Sean Barrett (@nothings) also contributed to popularizing the IMGUI paradigm by publishing [an article in the September 2005 issue of Game Developer Magazine](https://archive.org/details/GDM_September_2005) (Page 34) and [accompanying sample code](http://silverspaceship.com/inner/imgui).
The concept has been privately researched before and after. [Thierry Excoffier's Zero Memory Widget](https://web.archive.org/web/20220516003813/https://perso.univ-lyon1.fr/thierry.excoffier/ZMW/) and his [research report](https://web.archive.org/web/20220516004122/https://perso.univ-lyon1.fr/thierry.excoffier/ZMW/rr_2003_03_11.pdf) in 2003 are also very notable although they didn't reach the game development sphere back then.
### Do we need a definition?
_"I kind of wish there was more radical experimentation in this space"_ ([tweet](https://twitter.com/pervognsen/status/1361241939593416705))
<BR>_"But, I need to store a variable therefore it isn't IMGUI anymore!!!"_ (many people)
<BR>_"But, the lib is storing a variable therefore it isn't IMGUI anymore!!!"_ (many people)
Nowadays I am starting to believe that the term has caused more harm than benefits, because it suggests there are two camps "IMGUI" vs "RMGUI". The reality is there is a continuum of possibilities over multiple unrelated axises. Many of them haven't been explored enough, as popular IMGUI libraries have been designed for certain needs and not others. Many of them are at reach as extension of existing popular frameworks. Some are likely to only ever exist as part of yet undeveloped IMGUI frameworks.
@@ -129,7 +130,7 @@ This is in comparison with typical RMGUI ("retained-mode UI"):
What it doesn't stands for:
- IMGUI does not mean that the library doesn't retain data.
- IMGUI does not mean that stuff are drawn immediately.
- IMGUI does not mean that stuff are drawn immediately or looks a certain way.
- IMGUI does not mean it needs a continuous loop nor need to refresh continuously.
- IMGUI does not mean it needs to refresh all-or-nothing.
- IMGUI does not mean that states are polled.
@@ -139,20 +140,16 @@ What it doesn't stands for:
- IMGUI does not mean that the library can or cannot support feature x or y.
- IMGUI does not mean that the library is more or less portable.
TODO: Each of those points should be explained with a paragraph. We could also describe how common UI libraries (of all types) stand on a given axis. We could also describe less explored paths and envision what new UI libraries could do.
TODO: Each of those points could be further developed. We could try to describe how common UI libraries (of all types) stand on a given topic. We could also describe less explored paths and envision what new UI libraries could do.
It's particularly important we develop this section to dissociate the promise (sometimes unfulfilled) vs current implementation. The full-feature bell-and-whistle promise is more likely to be ever fulfilled by a UI library if people understand that it is possible.
### Examples
_TODO_
### Modeless write-up
March 2022:
https://news.ycombinator.com/item?id=30814797
_"Immediate mode is a style of API where important state is kept in user code [editor note: this should be "user side" not "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."_
_"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."_
_"Counter intuitively 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."_