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

Question

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

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

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

关于延迟还有一个我不明白的含义。在chapter discussing IMGUI中的work-in-progress book by Johannes Norneby中，解释如下：

帧剪切

在实时环境中需要了解的 IMGUI 的一个方面 应用程序（每秒不断渲染新帧多次） 是用户交互总是对某些事情做出反应 是在前一帧上绘制的。这是因为用户界面必须 至少绘制一次，让用户知道有小部件 在那里进行交互。大多数情况下，这不会导致任何 如果帧速率足够高会出现问题，但这是有待解决的 知道。

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

Answer 1

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

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

很好 - 实施质量占主导地位，而不是系统特征。

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

我创建了一个包含大约 50% 的 UI 元素的 Spotify 克隆，并且渲染单个帧在微秒范围内。事实上，该应用程序始终使用少于 400 μs 的单个帧。在 60 Hz 显示器上启用 V-Sync 后，这相当于大约 3% 的 CPU 负载单个内核（每 16 毫秒 400 μs）对于简单的实现。此外，这 400 μs 中有相当一部分是由不会增加更多 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

玩得开心！