即时图形用户界面-是或否？[关闭]

几年前，我一直在使用许多“保留的” GUI系统（以下是我的意思）进行应用程序开发，例如MFC，QT，Forms，SWING和多个Web-GUI框架。我总是发现大多数GUI系统的概念过于复杂和笨拙。与应用程序中的其他部分相比，大量的回调事件，侦听器，数据副本，从字符串到字符串的内容-转换（等等）始终是错误和头痛的来源。（即使“正确”使用了数据绑定/模型）。

现在我正在写电脑游戏:)。到目前为止，我使用的是一个GUI：Miyagi（不知名，但与所有其他系统基本相同的Idea。）

那太差了。

对于像游戏这样的实时渲染环境，我觉得“保留的” GUI系统已经过时了。用户界面通常不需要自动布局或动态调整窗口大小。相反，他们需要与不断变化的数据进行非常有效的交互（例如世界上模型的3D位置）

几年前，我偶然发现了“ IMGUI”，它基本上类似于即时图形模式，但是用于用户界面。我没有太在意，因为我仍在进行应用程序开发，而IMGUI本身似乎并不广泛也不成功。仍然，他们采用的方法似乎是如此性感和优雅，以至于让我想使用这种UI方式为下一个项目编写一些东西（我未能说服工作中的任何人：（...）

让我总结一下“保留”和“立即”的意思：

保留的GUI：在一个单独的初始化阶段，您将创建“ GUI控件”（如Labels，Buttons，TextBoxes等），并使用某种描述性（或编程性）方式将它们放置在屏幕上-始终在呈现任何内容之前。控件在内存中拥有大多数状态，例如X，Y位置，大小，边框，子控件，标签文本，图像等。您可以添加回调和侦听器，以了解事件并更新GUI控件中的数据。

即时GUI：GUI库由一次性“ RenderButton”，“ RenderLabel”，“ RenderTextBox” ...功能组成（编辑：不要被Render弄糊涂字首。这些功能还可以执行控件背后的逻辑，例如轮询用户输入，插入字符，在用户按住键时处理字符重复速度等...），您可以调用它们以“立即”呈现控件（doesn'不必立即将其写入GPU。通常会记住当前帧的GPU，并在以后将其分类。这些库不包含任何“状态”。如果要隐藏按钮...，请不要调用RenderButton函数。所有具有用户交互作用的RenderXXX函数（如按钮或复选框）都具有返回值，这些返回值指示例如用户是否单击了按钮。所以你的“ RenderGUI” 函数看起来像一个很大的if / else函数，您可以在其中调用或不调用RenderXXX函数，具体取决于游戏状态，并且所有数据更新逻辑（当按下按钮时）都将插入到流程中。所有数据存储都在gui的“外部”，并按需传递给Render函数。（当然，您可以将大功能分成几个功能，或使用一些类抽象来对gui的各个部分进行分组。我们不再像1980年那样编写代码了，对吗？））

现在，我发现Unity3D实际上对其内置GUI系统使用了完全相同的基本方法。也可能有两种使用这种方法的GUI？

仍然..环顾四周时，似乎对保留的GUI系统有强烈的偏见？至少我没有在Unity3D中找到这种方法，并且原始的IMGUI社区似乎相当安静。

因此，有人同时使用这两种想法并有强烈的见解？

编辑：我对来自现实经验的观点最感兴趣。我认为IMGUI论坛中有很多关于直接GUI方法的“理论缺陷”的热烈讨论，但是我总是发现了解现实中的缺陷会更具有启发性。

没错 我已经在糟糕的“保留模式” GUI和糟糕的“即时模式” GUI上完成了付费gamedev的工作，尽管两者都使我望而却步，但是保留模式方法显然仍然是更好的方法。

立即模式的缺点很多：

• 它们使艺术家和设计师难以轻松配置布局；
• 它们使您将逻辑与演示结合起来；
• 它们使拥有单一一致的输入模型变得更加困难；
• 他们不鼓励对动态数据进行复杂的控制（例如，列表视图）；
• 分层变得非常尴尬（例如，如果我调用RenderComboBox，则下拉框可能无法呈现，因为它需要位于窗口的其余部分上方-与工具提示相同）
• 配置渲染样式最终需要使用全局变量（ick）或其他函数参数（ick）完成；
• 性能可能很差，因为调用所有这些函数来查询可能已更改或未更改的值往往会创建许多小对象，从而给内存管理器造成压力；
• ...而且我什至无法想象允许某人在GUI周围拖动并重新排序会是多么痛苦。您必须维护一个数据结构，告诉您在哪里渲染所有内容-就像您自己重写保留模式系统一样。

即时模式GUI吸引了想要快速HUD系统的独行程序员，因此，它们很棒。对于其他什么...只要说不。

作为在台式机上使用IMGUI有5到6年实际经验的人，我有义务捍卫它。所有答复（以及问题本身）都是基于对IMGUI的非常严格的定义，并且似乎有很多可疑的声明。

很多原因是因为IMGUI库无法在后台保留任何数据。这根本不是真的。实际上，复杂的IMGUI库将保留与等效RMGUI库一样多的数据。区别在于，IMGUI库主要缓存结果，而RMGUI库则维护权威状态。在IMGUI中，应用程序提供了一种功能，该功能采用当前模型状态并为该状态生成GUI。这是GUI的权威定义。该库负责确保屏幕上的GUI与该功能的结果匹配。这并不意味着它需要在每个框架上全面评估该功能并完全重建GUI。这就是缓存的重点。

使用IMGUI的这种视图，您实际上可以进行高级布局，并且性能相当合理。如果使界面更容易，您也可以保留实际的权威状态。IMGUI的目的不是要使应用程序保留所有内容。该应用程序可能不想存储每个滚动条的位置以及每个树节点的展开/折叠状态。关键是要能够在程序上指定这些树节点的内容及其存在。

我会逐点回答所有的IMGUI批评，但是我并不太了解。它们中的大多数似乎是基于一些基本的信念，即IMGUI是hackish的，而RMGUI是结构良好的，我想这是由于上述误解造成的。没有固有的原因，IMGUI库应该在复杂性方面遇到麻烦，或者必须在全局变量中杂乱无章或将逻辑与表示混合在一起。我要说的是，IMGUI的优点随着艺术家驱动的内容的增加而变得不那么重要，但是我不确定为什么对于艺术家驱动的内容它实际上会更糟。（除了样式表之外，我个人不使用艺术家驱动的内容，例如颜色，字体/边框大小等，但是我不明白为什么比RMGUI难实现。）

在我看来，IMGUI无疑是一件好事。它为您提供有关GUI推理的更好模型。它变得更具功能性和反应性，并且您可以将必须​​推理的可变状态量降至最低。另一方面，实现复杂的IMGUI库是一个挑战，而且绝对比实现等效的RMGUI库困难。这是库复杂性和应用程序复杂性之间的权衡。如果您打算构建复杂的应用程序（甚至很多简单的应用程序），那么权衡是非常好的。如果您要针对一个应用程序执行此操作，而且非常简单，那么使用RMGUI可能会更快地实现目标。

无论如何，祝你好运！

GUI库由一个一次性的“ RenderButton”，“ RenderLabel”，“ RenderTextBox” ...组成，您可以调用这些函数“立即”呈现一个控件（不必立即写入GPU。通常记住它（目前的画面），稍后再分类。

我什至可以说这不构成GUI库。这只是一堆渲染功能。

渲染GUI是制作GUI 最简单的部分。以一个文本框为例。我将假设最简单的情况：一个简单的单行输入文本框。

RenderTextBox只会绘制一个文本框。它将执行一些简单的文本测量并在屏幕上绘制字形。它不会

• 检测用户已单击控件中的鼠标，然后将光标移动到字符串中的适当位置。
• 检测到用户双击控件中的鼠标并选择一个文本块。
• 检测到用户按下“ Home”键，然后将光标移到文本的前面。
• 检测到用户按下了有效键，并相应地修改了字符串。如果选择了文本，则所选部分将被插入的文本替换。

我可以继续前进，但我认为我的观点很明确。如果要用来RenderTextBox绘制文本框，您将得到的只是一个静态的，无法正常工作的文本框。任何实际功能都必须由您实现。

做文字测量和绘制字形吗？那是GUI工作的简单部分。GUI代表“图形用户界面”。最后两个词是您很难的部分，您可以从用户那里获取输入并对其进行处理。

游戏玩家期望GUI控件能够正常工作。在PC风格的环境中（例如：鼠标和键盘），如果玩家看到一个文本框，他们希望它像普通的文本框一样工作。他们希望能够使用箭头键在其中移动，跳转到前端并以home结束并删除，选择其中的字母等。

这意味着您将必须实现所有这些UI代码。您必须测试单击了哪个控件。然后，您必须根据单击的控件来执行某些操作。您必须具有“活动”控件的概念，该控件需要键盘输入。不同的控件必须对不同类型的用户交互做出不同的响应。

基本上，您将需要一TextBoxWindow堂课。

假设您正在实现游戏选项屏幕。因此，您有不同的选项组：游戏性，图形，声音，控件等。因此，在屏幕的左侧有一个不同组的列表。每个组调出一系列用户可以操纵的控件。当用户按下Tab键时会发生什么？

好吧，这取决于激活的控件。如果组控件中的一个处于活动状态（最近被单击），则它将移至下一个组。相反，如果该组中的一个控件处于活动状态，则它将移至该组中的下一个控件。这就是系统的预期工作方式。

因此，活动控件不仅必须处理键盘输入，而且现在还必须将所有未处理的输入都添加到拥有它的控件中。要么，要么控件必须在某种形式的链接列表中，以便它可以来回移动。这意味着每个控件中都必须有默认行为。

这听起来越来越像保留的GUI，不是吗？唯一的区别是…… 您是努力工作的人。使用别人的GUI 应该是减少工作量的一种方法。但是使GUI响应用户期望所付出的努力是不平凡的。

请记住：用户界面不适合您，它适合您的用户。是给玩家的。它应该表现出预期的效果。如果没有，那么您就失败了。

用户界面通常不需要自动布局或动态调整窗口大小。

那是一个有限而有限的思想。

我可以说一些关于具有不同UI需求的不同游戏，某些游戏确实需要可调整大小的窗口等的内容。但是，还有一个更大的问题。

您的这种思维方式会导致“无偿太空战”问题。

如果您从未玩过该游戏，那么它会是一款便宜，独立且非常GUI繁重的游戏。实际的游戏玩法全部在GUI中完成（这是一种“设置单位并观看它们战斗”的游戏）。问题？

不能取消GUI！

哦，如果您使用的是普通显示器或视力正常，这很好。但是，例如，如果您是我，却运行着一个可笑的巨大监视器（一个如此大的监视器，以至于Windows可以放大所有文本的大小，因此您实际上可以阅读它），那就太糟糕了。文字是微观的。无法更改字体大小。

当然，GSB是一款基于GUI的游戏，因此对他们来说绝对不可原谅。一个GUI精简版的游戏可能可以摆脱它。

永远不要以为您的用户完全按照自己的意愿看他们的游戏。这样做是愚蠢的。

真正的分辨率独立的GUI拥有可以自行调整以适应用户分辨率的GUI系统，因此需要将布局作为GUI系统本身的一部分。如果您不打算提供该功能，那么您的文字将在某人的巨型显示器上显得很小。这不是一件好事。

因此，我想说您对此问题的看法是短视的。您确实需要这些东西。您需要保留的GUI提供的内容。哦，您可能不需要任何特定GUI系统提供的一切。但是您需要一些。

将数据获取到系统所需要做的样板工作，是在合理保证用户可以与控件正确交互并且可以调整大小以适应播放器需求的同时，付出的代价很小。

如果您不从播放器中获取太多用户输入，则可能可以使用即时模式GUI。但是就这样。

不久前，IMGUI也引起了我的兴趣，作为测试，我编写了一些教程以使自己熟悉这些技术（如果您感兴趣，请从此处开始，但不超过C＃/ XNA + 此处的原始“教程” ）。 。

我真的很喜欢IMGUI一会儿，因为它们显示的信息始终是最新且正确的（因为没有状态，因此您始终会输入实际数据）。但是最后我失去了兴趣，所以现在通常我会再次使用保留的GUI。

最后，我认为GUI的即时性使GUI与数据的分离变得更加困难，有时我试图通过引入某种状态来打破事物之间的联系，从而打破IMGUI的风格。我也不认为为保留的GUI编写代码比为IMGUI编写代码更省力，我喜欢保留的GUI可以被触发并忘记，我真的很喜欢事件:)。

但是，每次有人提到IMGUI时，我内心都会想再尝试一次，并尽力将其改正，因为其中确实有一些优雅之处，我不确定百分百是否总是会让您的工作变得更轻松。我会说尝试一下，也许像我一样尝试并写一些教程（我发现学习新技术的最好方法是向他人解释新技术）。

我在Unity3D GUI系统上做了很多工作，该系统正如您所描述的那样工作。我必须说，我充满激情地讨厌它。

在某些情况下，“立即”方法确实有效。首先，当您只需要几个按钮和标签时​​-例如以射击游戏HUD为例。用“保留”方法创建它们并不是很难，但是使用UnityGUI则非常容易。第二种情况是您需要在屏幕上填充很多控件，但实际上并不关心布局。特别是在仅在运行时才知道确切的控件时。这实际上在任何游戏中都没有用，但是在使工具在Unity编辑器中运行时确实有用。

但是，任何半复杂的GUI（例如，用于（MMO）RPG或策略游戏的）都不可避免地会变成难以理解的可怕代码，充满特殊情况并以多种方式破坏。在构建这样的GUI时，通常具有非常特定的布局，该布局必须适用于任何分辨率，并且能够显示您发送的任何数据。例如，您需要将某些按钮移至较低位置以腾出较长的文本。使用“保留” GUI，您可以拥有一个自动执行此操作的控件。在“立即”模式下，没有控件，因此您必须明确地进行所有操作。

UnityGUI的另一个问题（不确定是否在所有即时模式的GUI中都发生）是，例如，Button()调用在不考虑任何其他GUI调用的情况下起作用。因此，如果一个按钮位于另一个按钮的顶部，则单击将同时按下两个按钮。这绝对不是用户期望的，因此这增加了另一个特殊情况要处理。

为了解决所有这些问题，我一直围绕着UnityGUI编写自己的包装程序，将其变成“保留”模式系统：存储自己状态的控件，只GUI为我每帧调用所需的函数。

我不能说“立即”模式肯定比“保留”模式差，但是在“保留”模式下工作肯定会好得多。

我将在这里为IMGUI辩护，因为如果您愿意为其编写代码，则可以解决前面列出的一些问题。另外，如果您确实为其编写了代码，那么您将拥有一个可重用的健壮的库，并且很少需要修改。

• 从架构加载GUI

也许一开始，艺术家似乎对IMGUI没有太多灵活性，这可以通过从xml或JSON模式加载GUI布局来解决或改进。

• 菜单层绘制调用

通过排序解决了此问题，您应该创建对绘制顺序进行排序的UI Manager类，我在C＃XNA中使用可移动的，可单击的面板相互重叠的方式解决了此问题。如果需要，我可以发布伪代码。

• 列表框

你可以从数组中绘制字符串吗？可以从这些字符串的字体的高度和宽度定义矩形区域吗？您是否可以创建滚动按钮的大小与所有这些矩形加在一起的高度之比？然后，您将创建带有向上或向下滚动按钮的列表框。我以为这会很困难，但是事实却比我想的要简单得多。没有缓冲区，没有状态，没有回调。

• 从GUI分离数据

不要让各个面板，按钮，盒子保存数据。我知道IMGUI的第一次尝试是即时的，但仅在图形意义上。我犯了在UI上保留数据的错误。通过UI更改对放置和修改数据的位置进行不同的思考几乎是一个哲学上的转变。

• SDK的GUI

这是SDK代码的限制和功能，而不是您的。我发现无论如何，SDK UI（Hammer，Unity，UDK）几乎都是一种新的语言。实际上，它们与我的Windows.Forms相似，都是为了最大可能而设置的，因此在复杂性方面有一些额外的权重。

最后看这个> http://mollyrocket.com/861

用户界面通常不需要自动布局或动态调整窗口大小。相反，他们需要与不断变化的数据进行非常有效的交互（例如世界上模型的3D位置）

这取决于所讨论的类型和游戏。一个好的库存管理系统对于大多数RPG都是至关重要的。您将需要一些可以为您处理布局的东西，支持滚动条，拖放，工具提示以及使用“保留的GUI”更易于实现的其他功能。

我想不出一种方法来拖拽即时图形用户界面（GUI），而无需花费太多时间或节省用户状态，例如临时更改Z缓冲区和存储时间信息以排除发生移动鼠标的点击。一点。

但是从设计角度来看，我很难想象没有GUI事件的世界。另外，即时GUI与OOP不兼容，迫使您诉诸程序编程。

即时图形用户界面（GUI）提供的简单性以代码的额外复杂性为代价，随着UI要求的复杂性的增加，代码的复杂性也迅速增加。一个好的保留GUI最初本来就比较复杂，但是扩展性更好。因此，在一定的复杂度以下，立即使用GUI即可满足要求，但对于大多数情况，我宁愿保留GUI。