与保留模式 GUI 相比，使用即时模式 GUI 对性能有何影响？

如何解决与保留模式 GUI 相比，使用即时模式 GUI 对性能有何影响？

由于似乎仍然对这个问题感兴趣（从观点来看），我想我不妨发布一个更新。

我最终实现了一个即时模式的 GUI 作为我的硕士论文，并且在性能方面有了一些数字。要点是：

与许多其他现有的保留模式 GUI 相比，我的即时模式实现通常执行得更快。范式之间的理论性能差异被大多数 GUI 非常未优化的事实所掩盖。总体而言，imgui 是一种完全可行的方法来创建响应快速且不会耗尽电池的 GUI。

我创建了一个包含大约 50% 的 UI 元素的 Spotify 克隆，并且渲染单个帧在微秒范围内。事实上，该应用程序在单个帧中始终使用不到 400 秒。在 60 Hz 显示器上启用 V-Sync 后，这相当于在一个简单的实现上大约 3% 的 cpu 负载 （ 每 16 毫秒 400 秒）。此外，这 400 个中的很大一部分是由不会增加更多 UI 元素的负载的恒定因素造成的（例如，接收输入或设置不随 UI 复杂性扩展的 GPU 状态）。

我内心的完美主义者仍然不喜欢什么都不做的 GUI 会消耗周期这一事实，但好处是巨大的： 当 GUI 被大量交互时，或者当窗口被调整大小时，它仍然达到 400 秒！ 这将许多现有的保留模式 GUI 彻底淘汰。尝试调整 Spotify、Windows Explorer、Visual Studio 或基本上任何其他桌面应用程序的大小，看看它是如何反应的，以理解我的意思。我的猜测是 Spotify 在我的 PC 上调整大小时会下降到大约 2 fps。

并且更改 UI 基本上是免费的。如果您在一帧中显示一百个按钮，然后在下一帧中将它们全部替换为文本框，那么性能仍然没有差异。保留模式的 GUI 在这种情况下往往会遇到困难。

还有三个想法：

• 大部分时间都花在了文本渲染上，其余的几乎无关紧要。如果你想进行大量优化，这将是重点。但即使很少优化，它也可以做得不错。

• 我怀疑性能上的巨大差异只能用保留模式和立即模式之间的差异来解释——甚至根本无法解释。例如，Spotify 为 UI 使用 Web 堆栈；那肯定会很慢。

我猜，WPF、Win32 之类的软件之所以慢，是因为它们可以侥幸逃脱，或者是因为它们针对与我们现在使用的完全不同的硬件进行了优化。当然，他们也做得更多，但远远不足以证明差异是合理的。

• 我确信您可以制作一个比我的即时模式 GUI 快得多的保留模式 GUI。老实说，总的来说，这几乎没有什么动力，这有点可悲。我喜欢有效率的东西。

更新

由于有几个人问，

请注意，您将看到一些不适合公开发布的东西，并且不会超过我个人对公开发布的软件的最低质量期望（这就是为什么我没有首先发布它的原因） . 因此，请仅将其用于教育目的，而不是用于构建实际软件。我也不会支持它。

下载内容包括论文本身（ ）、一些用于 Windows 的预构建可执行文件和源代码（C++）：

https://1drv.ms/u/s!AsdZfH5hzKtp9zy1YZtHgeSMApOp?e=FbxLUs

玩得开心！

解决方法

我目前正在开发一个标准的 Windows 桌面应用程序（标准意味着没有花哨的东西：只有按钮、文本、滑块等），并且在研究了一些 GUI
框架并被排斥后，决定自己编写一个 GUI 框架他们全部。由于它是一个爱好项目，我也愿意尝试，并决定制作 GUI
即时模式，而不是保留模式，因为我非常喜欢它简化代码的方式。不过，这是一个问题：

与保留模式 GUI 相比，在将其用于典型桌面应用程序时，使用即时模式 GUI 对性能有何影响？

我总是听说 IMGUI 性能更差，因为它必须重绘每一帧（或者，如果它以某种方式缓存，它仍然必须每帧执行逻辑）。但是我们在这里谈了多少？我会消耗两倍的 CPU
时间吗？更多的？如果我假设运行 20 个 IMGUI 程序，它会最大限度地利用
CPU（假设我已经优化了它）？我只想知道大致情况以及权衡在非游戏环境中是否仍然可行，在这种环境中不需要重绘每一帧。

关于延迟还有一个我不理解的含义。在Johannes
Norneby的一本工作中讨论
IMGUI
的章节中，解释如下：

剪框

在实时应用程序（每秒不断地多次渲染新帧）的上下文中要注意的 IMGUI
的一个方面是，用户交互将始终响应在前一帧上绘制的内容。这是因为用户界面必须至少绘制一次，以便用户知道那里有要与之交互的小部件。大多数情况下，如果帧速率足够高，这不会导致任何问题，但需要注意这一点。

这在保留模式 GUI 中有何不同？这是否意味着我比保留模式 GUI 多了一个输入延迟帧？