立即模式GUI性能 [英] immediate mode GUI performance
问题描述
我目前正在使用标准的Windows桌面应用程序（标准意味着没有花哨的东西，只有按钮，文本，滑块和其他东西），在研究了一些GUI-Frameworks和软件后，我决定自己编写GUI框架。被所有人排斥的蜜蜂。由于这是一个业余项目，所以我也愿意尝试，并决定不保留GUI即时模式，因为我真的很喜欢它简化代码的方式。这是一个问题：
I am currently working on a standard windows desktop application (standard meaning no fancy stuff, just buttons, text, sliders and stuff) and have decided to write the gui-framework on my own, after looking into some GUI-Frameworks and beeing repelled by all of them. Since it's a hobby project I am also willing to experiment, and decided to make the GUI immediate mode, not retained, since I really like the way it simplifies the code. Here is the question:
在普通的桌面应用程序中使用即时模式GUI与保留模式GUI相比，对性能有何影响？
在这里，我总是认为imGUI的性能较差，因为它必须重绘每一帧（或者，如果以某种方式兑现，它仍然必须每帧）。但是，我们在这里还有多少呢？我要消耗两倍的CPU时间吗？更多？如果我假设运行了20个imGUI程序，它将占用CPU的最大空间吗？ （假设我已经对其进行了优化），我只是想知道棒球场，以及在非游戏环境中是否仍然需要进行权衡取舍，而无需重新绘制每一帧。
I always here that imGUI performs worse, since it has to redraw every frame (or, if it somehow cashes, it still has to do the logic every frame). But of how much more are we talking here? Am I burning twice the CPU time? more? If I hypothetically ran 20 imGUI programms, would it max out the CPU? (presuming I already optimized it) I just want to know the ballpark and if the tradeoffs are still viable in a non-game environment, where there is no need to redraw every frame.
我还不了解延迟的另一种含义。在此网站上对此进行了解释，如下所示：
There is also one more implication concerning latency that I don't understand. It is explained on this website like this:
剪切框
Frame shearing
IMGUI在实时
应用程序上下文中应注意的一个方面（不断地每秒多次渲染新帧）
是用户交互将始终是对在先前帧上绘制
的响应。这是因为用户界面必须至少绘制一次
，以使用户知道要与之交互的小部件
。在大多数情况下，如果帧速率足够高，这不会导致任何
问题，但这是
需注意的事情。
One aspect of IMGUI to be aware of in the context of real-time applications (constantly rendering new frames many times per second) is that user interactions will always be in response to something that was drawn on a previous frame. This is because the user interface must be drawn at least once for the user to be aware that there are widgets there to be interacted with. Most of the time this doesn't cause any problems if the frame rate is high enough, but it is something to be aware of.
在保留模式GUI中这有什么不同？
How is this any different in a retained mode GUI? Does that mean that I have one more frame of input lag over a retained mode GUI?
推荐答案
因为似乎有一些兴趣，这是否意味着我在保留模式GUI上还有一帧输入滞后？仍然在这个问题中（根据观点判断），我想我也应该发布一个更新：
Since there seems to be some interest in this question still (judging by the views), I thought I might aswell post an update:
我最终以我的硕士论文实现了即时模式GUI，性能上的一些数字。要点是：
I ended up implementing an immediate mode GUI as my masters thesis, and have some numbers in on the performance. The gist is:
即时模式在很多情况下会更好/更快，并且仅在某些情况下会更糟。总体而言，这是一种创建GUI的完全可行的方法，该GUI响应速度快且不会消耗电池电量。
我创建了一个Spotify克隆，其中大约有50％ UI元素的渲染和渲染单个帧的时间在微秒范围内。该应用程序对于单个帧始终达到<400us。在启用V-Sync和60 Hz监视器的情况下，这相当于单核CPU负载的3％（每16ms为400us）。此外：这400us中相当大的一块是恒定因素，不会随更多UI元素（例如输入或设置GPU）扩展。
I created a Spotify clone with about 50% of the UI-elements and rendering a single frame was in the microsecond range. The application consistently hit <400us for a single frame. With V-Sync enabled and a 60 Hz monitor, this equates to roughly 3% (400us per 16ms) CPU-Load on a single core. Furthermore: a decent chunk of these 400us were constant factors, that wouldn't scale with more UI elements (e.g. Input, or setting up GPU).
我的完美主义者仍然不喜欢一个不执行任何操作的GUI会消耗周期的事实，但是它的好处却是巨大的：当与GUI进行大量交互或调整窗口大小时，它仍然达到400us！这会将保留模式的GUI从水中吹走。尝试调整Spotify，Windows资源管理器，Visual Studio或基本上其他任何东西的大小，看看它们如何反应以理解我的意思。我想调整大小时，Spotify在PC上会下降到2 fps。
The perfectionist in me still dislikes the fact that a GUI that does nothing consumes cycles, but the upsides were tremendous: When the GUI was being heavily interacted with, or when the window was being resized, it was still hitting 400us! This blows retained-mode GUIs out of the water. Try resizing Spotify, Windows Explorer, Visual Studio or basically anything else and see how they react to understand what I mean. I would guess Spotify goes down to 2 fps on my PC when resizing.
更改用户界面基本上是免费的。如果您在一个框架中显示了100个按钮，然后在下一个中将它们全部交换为文本框，则性能仍然没有差异。同样，保留模式的GUI往往会在这种情况下挣扎。
Changing the UI is basically free. If you displayed 100 Buttons in a frame, and then exchange them all for Textboxes in the next, there is still no difference to the performance. Again, retained-mode GUIs tend to struggle with this scenario.
还有3个想法：
- 大部分时间都花在文本渲染上，其余时间几乎无关紧要。如果要大量优化，这将是一个难题。
- 我怀疑巨大的性能差异仅是或什至主要是由于保留模式与即时模式之间的差异所致。例如，Spotify将Web堆栈用于UI，那肯定很慢。我想WPF，Win32之类的程序之所以运行缓慢，是因为它们可以摆脱它，或者因为它们针对与我们现在完全不同的PC进行了优化。他们还可以做更多的事情，但远不能证明这种差异。
- 我确信您可以制作一个保留模式的GUI，它比我的即时模式GUI快得多。一般来说，这样做的动机很少，这有点令人遗憾。我喜欢高效的东西。
对我来说，关键的方法是：很好，您可以快速实现。
The key takeway for me is: It's fine, You can make it fast.
这篇关于立即模式GUI性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
