与保留模式 GUI 相比，使用即时模式 GUI 对性能的影响是什么？

我目前正在开发一个标准的 Windows 桌面应用程序(标准意味着没有花哨的东西: 只有按钮、文本、滑块等) ，在研究了一些图形用户界面框架后，我决定自己编写一个图形用户界面框架。由于这是一个业余爱好项目，我也愿意尝试，并决定使 GUI 立即模式，而不是保留模式，因为我真的很喜欢它简化代码的方式。但问题是:

在典型的桌面应用程序中，与保留模式 GUI 相比，使用即时模式 GUI 对性能的影响是什么？

我总是听说 IMGUI 表现得更差，因为它必须重绘每一帧(或者，如果它以某种方式缓存，它仍然必须做每一帧的逻辑)。但我们还要谈多少呢？我是不是烧掉了两倍的 CPU 时间？还要吗？如果我假设运行20个 IMGUI 程序，它是否会最大化 CPU (假设我已经优化了它) ？我只是想知道球场的大致情况，以及在非游戏环境中这种权衡是否仍然可行，因为在非游戏环境中没有必要重新绘制每一帧图像。

还有一个关于延迟的暗示，我不明白。在 约翰尼斯 · 诺尔内比的 在制作中的书的 讨论图形用户界面的章节中，解释如下:

框架剪切

IMGUI 在实时环境中需要注意的一个方面 应用程序(每秒多次不断渲染新帧) 就是用户交互总是响应 这是因为用户界面必须 至少绘制一次，以便用户知道有小部件 大多数情况下，这不会引起任何 问题，如果帧速率是足够高，但它是一些 意识到。

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

47590 次浏览
小开
最佳答案

由于这个问题似乎仍然有一些兴趣(根据观点判断) ，我想我不妨发布一个更新。

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

它的优良实现质量占主导地位，而不是系统特征。

与许多其他现有的保留模式 GUI 相比，我的即时模式实现通常执行得快得多。这些范例之间的理论性能差异因为大多数 GUI 都没有得到可怕的优化而黯然失色。总的来说，imgui 是一个完全可行的方法来创建一个快速响应和不消耗电池的 GUI。

我用大约50% 的 UI 元素创建了一个 Spotify 克隆，渲染一个框架在微秒级范围内。事实上，应用程序在单帧时一直使用不到400μs。在60Hz 的监视器上启用 V-Sync，这相当于大约3% 的 CPU 负载 在一个核心上(400μs/16ms) 一个幼稚的实现。此外，这400μs 中有相当一部分是由不会增加更多 UI 元素负载的常量因素造成的(例如，接收输入或设置 GPU 状态，不能根据 UI 复杂性进行扩展)。

我内心的完美主义者仍然不喜欢一个什么都不做的 GUI 正在消耗周期的事实，但好处是巨大的: 当图形用户界面被大量使用时，或者当窗口被调整大小时，它仍然可以达到400μs！这将许多现有的保留模式 GUI 吹出了水面。尝试调整 Spotify、文件资源管理器、 Visual Studio 或其他任何桌面应用程序的大小，看看它的反应，以理解我的意思。我的猜测是，当调整大小时，Spotify 在我的电脑上的速度会降到2 fps 左右。

改变用户界面基本上是免费的。如果在一帧中显示100个按钮，然后在下一帧中用文本框替换所有按钮，那么性能仍然没有差异。在这种情况下，保留模式 GUI 往往难以实现。

还有三个想法:

  • 大部分时间花在文本渲染上，其余的时间几乎无关紧要。如果您想要大量优化，这将是重点关注的事情。但即使没有什么优化，它也可以做得很好。

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

    我想，WPF，Win32，和其他类似的软件之所以慢是因为它们可以不受影响，或者是因为它们针对与我们现在使用的硬件完全不同的硬件进行了优化。当然，他们也做得更多，但远远不足以证明这种差异的合理性。

  • 我相信您可以制作一个保留模式的 GUI，它比我的即时模式 GUI 快得多。总的来说，几乎没有什么激励因素，说实话，这有点可悲; 我喜欢高效率的东西。

更新

既然有人问起，我决定发表我的论文。

请注意，您将看到的东西并不是为了公开发布，也不符合我个人对公开发布的软件的最低质量期望(这就是我一开始没有发布它的原因)。因此，请只将它用于教育目的，而不是用它来构建实际的软件。我也不会支持的。

下载包括论文本身(用德语！) ，一些 Windows 预构建的可执行文件，以及源代码(C + +) :

Https://1drv.ms/u/s ! asdzfh5hzktp9zy1yzthgeSMapope = fbxLUs

玩得开心！


提交答案