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

Question

我目前正在开发一个标准的 Windows 桌面应用程序(标准意味着没有花哨的东西:只有按钮、文本、 slider 等)，并且在研究了一些 GUI 框架并被排斥后，决定自己编写一个 GUI 框架他们都是。由于这是一个爱好项目，我也愿意尝试，并决定制作 GUI 即时模式，而不是保留模式，因为我非常喜欢它简化代码的方式。不过，这是一个问题:
与保留模式 GUI 相比，在将其用于典型桌面应用程序时，使用即时模式 GUI 对性能有何影响？
我总是听说 IMGUI 性能更差，因为它必须重绘每一帧(或者，如果它以某种方式缓存，它仍然必须每帧都执行逻辑)。但是我们在这里谈了多少？我会消耗两倍的 CPU 时间吗？更多的？如果我假设运行 20 个 IMGUI 程序，它会最大限度地使用 CPU(假设我已经对其进行了优化)？我只是想知道大致情况以及权衡在非游戏环境中是否仍然可行，在这种环境中不需要重绘每一帧。
关于延迟还有一个我不理解的含义。在 chapter discussing IMGUI在 work-in-progress book由 Johannes Norneby ，解释如下:

Frame shearing

One aspect of IMGUI to be aware of in the context of real-timeapplications (constantly rendering new frames many times per second)is that user interactions will always be in response to something thatwas drawn on a previous frame. This is because the user interface mustbe drawn at least once for the user to be aware that there are widgetsthere to be interacted with. Most of the time this doesn’t cause anyproblems if the frame rate is high enough, but it is something to beaware of.

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

Answer 1

由于似乎仍然对这个问题感兴趣(从观点来看)，我想我不妨发布一个更新。
我最终实现了一个即时模式的 GUI 作为我的硕士论文，并且在性能方面有一些数据。要点是:
很好 - 实现质量占主导地位，而不是系统特征。
与许多其他现有的保留模式 GUI 相比，我的即时模式实现通常执行得更快。范式之间的理论性能差异被大多数 GUI 非常未优化的事实所掩盖。总体而言，imgui 是一种完全可行的方法来创建响应快速且不会耗尽电池的 GUI。
我创建了一个包含大约 50% 的 UI 元素的 Spotify 克隆，并且渲染单个帧在微秒范围内。事实上，该应用程序始终使用少于 400 μs 的单个帧。在 60 Hz 显示器上启用 V-Sync 后，这相当于单核上大约 3% 的 CPU 负载(每 16 毫秒 400 微秒)，这是一个简单的实现。此外，这 400 μs 中有相当一部分是由不会增加更多 UI 元素的负载的恒定因素造成的(例如，接收输入或设置不随 UI 复杂性扩展的 GPU 状态)。
我的完美主义者仍然不喜欢一个不做任何事情的 GUI 会消耗周期这一事实，但好处是巨大的:当 GUI 被大量交互时，或者当窗口被调整大小时，它仍然达到 400 微秒!这将许多现有的保留模式 GUI 彻底淘汰。尝试调整 Spotify、Windows Explorer、Visual Studio 或基本上任何其他桌面应用程序的大小，看看它是如何 react 的，以理解我的意思。我的猜测是 Spotify 在我的 PC 上调整大小时会下降到大约 2 fps。
并且更改 UI 基本上是免费的。如果您在一帧中显示一百个按钮，然后在下一帧中将它们全部替换为文本框，那么性能仍然没有差异。保留模式的 GUI 在这种情况下往往会遇到困难。
还有三个想法:

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

我怀疑性能上的巨大差异只能——甚至根本不能——通过保留模式和立即模式之间的差异来解释。例如，Spotify 为 UI 使用 Web 堆栈；那肯定会很慢。
我猜，WPF、Win32 之类的软件很慢，因为它们可以侥幸逃脱，或者因为它们针对与我们现在使用的完全不同的硬件进行了优化。当然，他们也做得更多，但远远不足以证明差异是合理的。

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

更新
由于有几个人问， 我决定发表我的论文。
请注意，您将看到不打算公开发布的东西，并且没有达到我个人对公开发布软件的最低质量期望(这就是我一开始没有发布它的原因)。因此，请仅将其用于教育目的，而不是用于构建实际软件。我也不会支持它。
下载内容包括论文本身( 德语!)、一些用于 Windows 的预构建可执行文件和源代码(C++ 中):
https://1drv.ms/u/s!AsdZfH5hzKtp9zy1YZtHgeSMApOp?e=FbxLUs
玩得开心!