Wiki page about the IMGUI paradigm

[ocornut]

I drafted an article here:
https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradigm

It's not much of a definition, almost a non-definition.
This thread is a place for us to discuss its contents and how we could move it forward.
This is not an article about Dear ImGui (but will refer to it)

It's been frustrating to witness the amount of misunderstanding, misleading or incorrect statements written on the internet about this. I would hope we over time can draft a simple article that would help dissipate many of the misunderstandings.

I also hope that we can make it clear that there are a lots of things yet to explore and improve in UI programming land, and Dear ImGui as of today is only a fraction of what could be achieved.

Side-quest

Let's find a new meaning for the "IM" letters and pretend it always have been that?

Idiomatically Marvelous Graphical User Interface
Incredibly Magic Graphical User Interface
Infamously Misunderstood Graphical User Interface
Intuitive & Malleable Graphical User Interface

[PathogenDavid]

Infamously Misunderstood Graphical User Interface

😄 This gets my vote

Maybe you can just change what the IM stands for with every release.

---

This will be a great resource to share with people who want to learn more about the philosophy behind Dear ImGui and similar libraries.

I think it would be useful to add a tiny paragraph to the very beginning clarifying that this article is about the IMGUI paradigm/philosophy with some noteworthy examples. Anyone who reads the whole thing will get that, but I'm worried about those who will skim. Something along the lines of:

This page describes the general concept of the IMGUI paradigm, of which Dear ImGui is one such implementation. Some other prominent examples include Nuklear and Unity's editor UI.

(Unity's IMGUI system can be used in-game too, but it's generally associated with being used for editor stuff. So that wording could be considered misleading. Unity has three different UI systems and only one of them is an IMGUI.)

[heroboy]

Is react IMGUI? Especally the function component.

If I draw all things in the windows WM_PAINT message, is it the IMGUI?

[ghost]

Maybe the most clarifying thing is the difference between the usage of these two paradigms, in code. It's what gave me my first "a-ha" moment, at any rate. Perhaps a starting point for understanding could be a contrasting retained mode example to compare against the imgui approach, such as the following pseudocode:

func callback:
  print("Button click! Message: " + inputText.getText())
  
func setupGui:
  TextBox inputText = gui.createTextBox(x1, y1, w1, h1)
  Button submit = gui.createButton(x2, y2, w2, h2, "Submit")
  submit.onClick = callback
  
func cleanupGui:
  gui.destroy(inputText)
  gui.destroy(submit)

func processInput input:
  foreach item in gui.items()
    item.processInput(input)
    
func drawGui:
  foreach item in gui.items().sortByZ()
    item.draw()

vs.

string message

func doGui input:
  gui.textBox(input, x1, y1, w1, h1, message)
  if gui.button(input, x2, y2, w2, h2, "Submit") then
    print("Button click! Message: " + message)

To me at least, this pretty clearly shows that "imgui means zero state!" is a bit misleading -- what is the message variable, other than state? And yet, the imgui approach is obviously quite different. "Read on to learn more..."

I'm thinking of this like learning calculus. For some people, it's easier to start with "dx just means 'a little bit of x'" rather than the limit theorem, and progress from there (you'll eventually get to the limit theorem anyway). Likewise, it might easier to start with this simple example of the imgui vs. rmgui approaches, and then walk through progressively more complex examples with commentary along the way.

[Xiliusha]

Chinese Translation (WIP), I'll keep it up to date:

关于IMGUI范式

这只是一份半成品、草稿 | 本文讨论

为什么？

这是在试图解释IMGUI范式代表什么，以及它可能是什么。

IMGUI范式的支持者已经注意到它被广泛地一次又一次地误解了。
截至2021年2月，即使是IMGUI维基百科页面也完全是不准确的。理由如下:

• 这个缩写很容易引起误解。
• 人们没有很好地解释或记录IMGUI意味着什么?
• 他们对IMGUI的意思有不同的解释?
• 许多流行的IMGUI实现都做出了类似的设计选择，这使得IMGUI范式的灵魂和支柱与一组实现上的选择相比更加令人困惑。
• “Dear ImGui”的命名和成功让这条界限变得模糊了一点(其实应该用另一个名字)。

这个缩写词非常具有误导性，因为“immediate-mode”（立即模式）最初是作为一个过时的图形API的参考而被创造出来的，它使得渲染内容变得非常容易。这个词的选择让我们陷入了多年，甚至几十年的误解。

从现在开始，IMGUI将代表“Incredibly Magic Graphics User Interface”（难以置信的魔法图形用户界面） :)

这个页面的第二个目的是应该明确在UI编程中有很大的探索空间。

历史

首字母缩写IMGUI是由Casey Muratori在2005年的这段视频中创造的：
https://www.youtube.com/watch?v=Z1qyvQsjK5Y （参考博客）

“我还看到很多人争论即时模式和保留模式的GUI api。我认为这与IMGUI概念的简单程度有关，因为它会让人们认为自己理解了它，然后就会进入激烈的争论，就好像他们真的知道自己在说什么一样。当我谈论任何稍微复杂的东西时，比如四元数，我很少看到这个问题。”

在此之前和之后都有过私人研究。
Casey在制定和推广这一课题的研究方面所做的工作是无价的。然而，我认为选择“immediate-mode”这个词是一个错误，十年后，我们仍然在为误解IMGUI的含义而付出代价。

我们需要一个定义吗?

“我希望在这个领域有更多激进的实验” tweet

现在，我开始相信这个词弊大于利，因为它表明有两个阵营“IMGUI”和“RMGUI”。现实是在多个不相关的坐标轴上存在一个连续的可能性。其中许多还没有得到足够的研究，因为流行的IMGUI库是为某些需求而不是其他需求而设计的。它们中的许多都是现有流行框架的扩展。有些可能只存在于尚未开发的IMGUI框架中。

这两个术语的存在有效地阻碍了讨论和研究。事实上，我们试图将一个官方定义放在一个标签上，这阻碍了人们对许多可能的UI领域研究领域的想象。

算是半个定义

@ocornut 对定义的尝试（半成品，2021）

我们关心的是：

• IMGUI指的是API:字面上是应用程序和UI系统之间的接口。
  • API试图最小化应用程序必须保留的与UI系统相关的数据。
  • API试图最小化UI系统必须保留的与应用程序相关的数据。
• IMGUI不是指实现。UI系统内发生的任何事情都不重要。

这与典型的RMGUI（“retained-mode UI”，保留模式UI）相比：

• RMGUI API经常让应用程序保留来自UI系统的构件(例如维护对UI对象的引用)。
• RMGUI API经常需要同步机制，因为UI系统保留了更多的应用程序数据。

它不代表的含义：

• IMGUI并不意味着这个库不保留数据。
• IMGUI并不意味着内容是立即绘制的。
• IMGUI并不意味着它需要一个连续的循环，也不需要连续刷新。
• IMGUI并不意味着它需要全部刷新或者不刷新。
• IMGUI并不意味着状态是轮询的。
• IMGUI并不意味着UI看起来不像“原生的”或看起来是这样。
• IMGUI并不意味着它不能加动画。
• IMGUI并不意味着它需要GPU来渲染。
• IMGUI并不意味着库可以或不能支持特性x或y。
• IMGUI并不意味着这个库具有较高或较低的可移植性。

未完成：每一个要点都应该用一段话来解释。我们还可以描述通用的UI库（所有类型的）是如何位于给定坐标轴上的。我们也可以描述较少探索的路径，并设想新的UI库可以做什么。

我们将这一节发展到将约定（Promise）（有时未实现）与当前实现分离开来是特别重要的。如果人们明白这是可能的，那么UI库就更有可能实现功能齐全的约定。

实例

未完成

Vurtun 的捧场文章

译者注：不要加上斜体，不然中文文字很难看清

@vurtun 在2019年4月那会痛诉道：

”我通常不喜欢提到即时模式UI（immediate mode UI），因为关于它们有很多先入为主的概念。解决所有这些问题是困难的，因为这通常是必需的，因为它们都是同时抛出的。例如，一个概念的单一实现并不能定义一个概念（Dear ImGui是一个不是所有的IMGUI都像Dear ImGui一样的即时模式UI）。

所有可以用“保留”模式GUI完成的事情都可以通过立即模式GUI完成（在这一点上我讨厌整个划分）。然后是状态。出于某些原因，就像Andrew已经说过的，我经常看到人们混淆了立即模式意味着无状态。立即模式与状态如何存储或是否存储无关。GUI中的立即模式并不会去除两种数据表示。一个在调用的地方，一个在库中。即使是Dear ImGui和Nuclear都有自己的内部状态。立即模式的核心是如何更新状态。在经典的GUI中，应用程序的状态通过修改与GUI状态同步。另一方面，立即模式更接近于函数式编程。所有先前的状态都是不可变的，新的状态只能通过获取以前的状态并应用新的更改来生成，而不是变化的状态。在Dear ImGui和Nuclear中都很少有之前的状态，大多数都是建立在每一“帧”上。

接下来处理小部件事件（按下、点击、……）。立即模式与事件无关，与轮询输入更改无关。if (button(...)) 以方便著称。您甚至可以保留使用轮询而不是事件的库。

然后是“即时模式捆绑了布局，输入和渲染”。再说一次，只有Dear ImGui和Nuclear才这么做。在这一点上，我所有的IMGUI们都有多个通道。例如，如果我缓存布局的状态（布局，输入，渲染）。输入或渲染通道的任何更改都将跳转回布局。如果我不缓存布局的状态，我仍然有两个通道（输入，渲染），以防止故障。为了确保性能不成问题，我确保只更新那些实际可见的元素，这对数据结构（列表、树）很重要。不可见的小部件不仅没有呈现，也没有布局或输入处理。在当前实现中，它们甚至不会被遍历。

我听到的另一个争论是，立即模式不能于面向对象（OOP）一起使用。虽然我试图远离这个术语，因为它有太多的含义，基本上是没有讨论价值的，但我在来龙去脉中听到的是小部件的可组合性。再一次，仅仅因为Dear ImGui和Nuclear没有，并不意味着它必须是或者甚至应该是那样。例如，我们工作中的IMGUI支持可组合性，就像保留模式UI们一样，你可以把任何小部件放在任何其他小部件中。想要一个滑块在一个选项卡中，你可以组合它们（在这种情况下，这也说不通）。

轮到游戏UI对比工具UI。免责声明：我花了大部分时间在工具UI上，然而我也在游戏UI上花了很多时间，或者说在我的即时/保留模式混合下的背后的概念（https://gist.github.com/vurtun/c5b0374c27d2f5e9905bfbe7431d9dc0）。

就我个人而言，工具和游戏UI是两个完全不同的用例。有趣的是，我们实际上有一个单一的即时模式核心，用于游戏和工具UI而它仍然有效。然而，我们的优势是我们的UI设计师可以写代码。即时模式最大的优点是状态改变极其简单容易。然而，在游戏中，列表等数据结构之外的所有UI（包括动画等内容）都是在编译或加载时才知道的。因此，即时模式的大多数优点都无法支撑（除了提到的数据结构之外）。有趣的是，对于数据结构，您甚至可以在保留状态UI中使用即时模式API。因此，拥有一种混合型，就能同时拥有两个世界的优点。

最后是状态处理。对于游戏来说，这就容易多了，因为大多数状态都是预先知道的，并且可以预先分配。对于工具UI，它有点复杂。首先，可以为每个小部件设置状态。这就是我们目前在keen core所做的。状态本身在生命周期中被跟踪，如果不再使用则释放。然而，真正可能的是拥有窗口、视图的概念并管理库外的状态。我的意思是一个带有内容的选项卡窗口。例如，日志视图或场景视图存储了UI所需的所有状态和实际所需的数据（日志视图的日志条目）。与其尝试在小部件级别上进行状态处理，不如在视图本身中进行状态管理更有意义，因为与实际的小部件不同，视图本身具有很容易跟踪的生存期。澄清一下，库API中的视图只是一个句柄，而实际的视图实现将存储状态。

UI中的很多内容都取决于所面临的问题，所以我觉得没有什么灵丹妙药。但UI真正伟大的地方在于，它可以编写一个适合这个问题的版本。我希望从这段碎碎念中可以看出，“IMGUI”目前涉及了许多概念，但这些概念并没有定义它。所以每次当它不能发挥作用时，作为一个宏大概念的立即模式本身就会被抛到一边，而不是重新评估那些不能发挥作用的部分。“

相关链接

• Johannes 'johno' Norneby's article, 2007.
• A presentation by Rickard Gustafsson and Johannes Algelind, 2011.
• Jari Komppa's tutorial on building an IMGUI library, @jarikomppa, 2006.
• Casey Muratori's original video that popularized the concept, 2005.
• Nicolas Guillemot's CppCon'16 flash-talk about Dear ImGui, 2016.
• Thierry Excoffier's ZMV (Zero Memory Widget), 2004.
• Unity's IMGUI

[neopolitans]

I'm a student in my last year doing Games Programming and I've often found it hard to explain to others around me parts of Immediate-Mode GUI as a whole. Honestly, even as a draft, this wiki page is excellent from my point of view. It encapsulates a lot of information and outlines a lot of misconceptions.

I wish I could contribute more to Dear Imgui but thank you all for making and drafting this wiki page.