未答复的用户对其MS论文提出疑问并在2年后自行回答

我目前正在开发一个标准的Windows桌面应用程序（该标准意味着没有花哨的东西：仅是按钮，文本，滑块等），在研究了一些GUI框架并遭到排斥之后，我决定自己编写一个GUI框架。他们全部。由于这是一个业余项目，我也愿意尝试一下，并决定使GUI立即模式，而不是保留模式，因为我真的很喜欢它简化代码的方式。不过，这是一个问题：

在典型的桌面应用程序中使用立即模式GUI和保留模式GUI相比，使用立即模式GUI会对性能产生什么影响？

我总是听到IMGUI的性能较差，因为它必须重绘每一帧（或者，如果以某种方式缓存，它仍然必须在每一帧进行逻辑运算）。但是，我们在这里还有多少呢？我要消耗两倍的CPU时间吗？更多？如果我假设运行了20个IMGUI程序，它会最大化CPU（假设我已经对其进行了优化）吗？我只想了解球场，以及在非游戏环境中权衡是否仍然可行，因为在非游戏环境中无需重新绘制每一帧。

我还不了解延迟的另一种含义。在约翰内斯·诺内比（Johannes Norneby）的一本进行中的书中讨论IMGUI的章节中，其解释如下：

IMGUI在实时应用程序上下文中（每秒不断渲染新帧多次）要意识到的一个方面是，用户交互将始终是对前一帧上绘制的内容的响应。这是因为必须至少绘制一次用户界面，以使用户知道此处有与之交互的窗口小部件。在大多数情况下，只要帧速率足够高，这都不会引起任何问题，但这是需要注意的。

在保留模式GUI中这有什么不同？这是否意味着我在保留模式GUI上还有一帧输入滞后？

我强烈建议您不要实现自己的GUI库，即使作为一个业余项目也是如此。正确的做法非常困难，并且有很多细节，而且容易出错。即使不存在您喜欢的GUI库，也最好将您的业余GUI库实现为现有库的薄包装器（基本上，将现有库之一与包装器一起使用，使API更像您想要的）。 GUI库太大，无法成为一个有趣的爱好项目 –贾斯汀

考虑一下您希望GUI库的详细程度或深度。例如，您是围绕OS api编写包装器，还是绕过OS并直接写入硬件？您应该查看WxWidgets和Qt来查看项目的规模。 –托马斯·马修斯

好吧，当我不再有乐趣时，我一定会停下来，现在我可以了，所以我会继续。我们将看到多长时间。不过，这与问题并没有真正的关系，如果我决定使用现有的GUI框架，我的观点对我也很重要：imGUI在非游戏环境中是否可行，如果是，对性能的影响是什么？ – \ pulp_user

我现在看到，我可能会强调它的一部分过于关注我自己的框架。无论是否会对性能产生影响，我都会以其他人的框架告终。 – \ pulp_user

立即模式渲染已经存在30多年了。它很直观，很好地使用了有限的硬件资源，利用了使小部件在主窗口中占据自己的位置的想法。保留模式渲染是一种截然不同的球类游戏，您可以＆quot;保留＆＃34;通过对GPU进行编程来渲染。与编写CPU上运行的代码相比，GPU可以做得更好，将像素散布到屏幕上的工作要好得多。但是您不能忽略对GPU进行编程的需要，并且其中不止一个。隐藏差异的是框架的工作。 –汉斯·帕桑特

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

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

在许多情况下，立即模式更好（更快），而在某些情况下更差（更慢）。总体而言，这是一种创建GUI的完全可行的方法，该GUI快速响应并且不会耗尽电池。

我用大约50％的UI元素创建了一个Spotify克隆，并且渲染单个帧的时间在微秒范围内。实际上，该应用程序单个帧始终使用少于400μs的时间。在60 Hz监视器上启用垂直同步后，这相当于单个内核上的CPU负载约为3％（每16毫秒400μs）。此外，这400μs中相当大的一部分是由恒定因素（例如，接收输入或设置GPU）导致的，不会因增加UI元素而增加负载。

我中的完美主义者仍然不喜欢这样的事实：一个无所事事的GUI会消耗很多时间，但好处是巨大的：当与GUI进行大量交互或调整窗口大小时，它仍然达到400μs！这会将保留模式的GUI从水中吹走。尝试调整Spotify，Windows资源管理器，Visual Studio或基本上任何其他桌面应用程序的大小，并查看其反应，以了解我的意思。我的猜测是调整大小时，Spotify在我的PC上会下降到约2 fps。

更改用户界面基本上是免费的。如果在一帧中显示一百个按钮，然后在下一帧中将它们全部替换为文本框，则性能仍然没有区别。在这种情况下，保留模式的GUI往往会遇到困难。

大部分时间都花在文本渲染上，其余时间几乎无关紧要。如果要大量优化，这将是一个难题。但是，即使没有进行任何优化，它也会很不错。

我怀疑性能的巨大差异是否只能或什至可以由保留模式和即时模式之间的差异来解释。例如，Spotify将Web堆栈用于UI。一定会很慢。

我想WPF，Win32之类的程序之所以缓慢，是因为它们可以摆脱它，或者是因为它们针对与当今使用的硬件完全不同的硬件进行了优化。当然，他们也做得更多，但远不能证明这种差异的合理性。

我确信您可以制作一个保留模式的GUI，它比我的即时模式的GUI快得多。总的来说，这样做没有什么动机，说实话，这有点令人遗憾。我喜欢高效的东西。

三年的答案。做得好！第一个问题：您如何比较这两种范例？第二个问题：您是否有指向项目实施细节的链接？谢谢！ –菲利普·吉恩（Philip Guin）

我只是意识到我并没有真正回答您的第一个问题：首先，我从理论的角度对它们进行了比较：在ImGUI中，您描述了希望UI具有的状态，在保留模式下，您指定了状态之间的过渡。我不会深入研究它，但归结为：保留模式的复杂度为n²，而即时模式几乎保持线性。然后，我构建了一个应用程序，以将性能与其他保留模式应用程序进行比较。这不是很科学，所以除了＆＃34;可以工作而且大多数情况下更好之外，没有真正的知识。 （对于我的用例）。 – \ pulp_user

很高兴您没有听取您说不应该写自己的评论的意见：)干得好。 – mohamedmoussa

恭喜您将其发布到Hacker News：news.ycombinator.com/item?id=25624044请绝对考虑共享您的代码，即使该代码是academic＆＃34;质量。只有好的才能实现。此外，这正是CRAPL许可证所针对的：p – Tasos Papastylianou

点击“发布答案”，即表示您同意我们的服务条款，隐私政策和Cookie政策

不是您要找的答案？浏览标记的其他问题或提出自己的问题。