与保留模式的GUI相比，使用立即模式的GUI对性能有何影响? [英] What are the performance implications of using an immediate-mode GUI compared to a retained-mode GUI?
问题描述
我目前正在开发一个标准的Windows桌面应用程序(该标准意味着没有花哨的东西:只是按钮，文本，滑块等)，在研究了一些GUI框架和被所有人排斥.由于这是一个业余项目，我也愿意尝试一下，并决定使GUI立即模式，而不是保留模式，因为我真的很喜欢它简化代码的方式.不过，这是一个问题:
I am currently working on a standard Windows desktop application (standard meaning no fancy stuff: just buttons, text, sliders, etc.), and have decided to write a GUI framework on my own, after looking into some GUI frameworks and being 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-mode, as I really like the way it simplifies the code. Here is the question, though:
在典型的桌面应用程序中使用即时模式GUI与保留模式GUI相比，对性能有何影响?
我总是听到IMGUI的性能较差，因为它必须重绘每一帧(或者，如果以某种方式缓存，它仍然必须在每一帧进行逻辑运算).但是，我们在这里还有多少呢?我要消耗两倍的CPU时间吗?更多的?如果我假设运行了20个IMGUI程序，它会最大化CPU(假设我已经对其进行了优化)吗?我只想知道棒球场，权衡取舍在非游戏环境中是否仍然可行，因为在非游戏环境中无需重新绘制每一帧.
I always hear that an IMGUI performs worse, since it has to redraw every frame (or, if it somehow caches, 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 programs, would it max out the CPU (presuming I already optimized it)? I just want to know the ballpark and whether 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. In the chapter discussing IMGUI in a work-in-progress book by Johannes Norneby, it is explained as follows:
剪板机
在实时上下文中需要注意的IMGUI的一个方面应用程序(每秒不断地多次渲染新帧)用户交互将始终是对某些事情的回应是在前一帧上绘制的.这是因为用户界面必须至少绘制一次，以使用户知道有小部件与之互动.在大多数情况下，这不会引起任何后果如果帧率足够高，就会出现问题，但这是有待解决的知道.
Frame shearing
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中有何不同?这是否意味着我在保留模式GUI上还有一帧输入滞后?
How is this any different in a retained-mode GUI? Does it mean that I have one more frame of input lag over a retained-mode GUI?
推荐答案
由于对这个问题似乎仍然有一些兴趣(根据观点判断)，我认为我不妨发布更新.
Since there seems to be some interest in this question still (judging by the views), I thought I might as well post an update.
我最终实现了即时模式GUI作为我的硕士论文，并且在性能上有了一些数字.要点是:
I ended up implementing an immediate-mode GUI as my master’s thesis, and have some numbers in on the performance. The gist is:
在很多情况下，即时模式更好(更快)，而在某些情况下更差(更慢).总体而言，这是一种创建GUI的完全可行的方法，该GUI快速响应并且不会耗尽电池.
我用大约50％的UI元素创建了一个Spotify克隆，并且渲染单个帧的时间在微秒范围内.实际上，该应用程序单个帧始终使用少于400μs的时间.在60 Hz监视器上启用垂直同步后，这相当于单个内核上的CPU负载(em> 大约为3％(每16ms400μs)).此外，这400μs中相当大的一部分是由恒定因素导致的，这些因素不会增加具有更多UI元素的负载(例如，接收输入或设置不随UI复杂性扩展的GPU状态).
I created a Spotify clone with about 50% of the UI elements, and rendering a single frame was in the microsecond range. In fact, the application consistently used less than 400 μs for a single frame. With V-Sync enabled on a 60 Hz monitor, this equates to roughly 3% CPU load on a single core (400 μs per 16 ms). Furthermore, a decent chunk of these 400 μs were caused by constant factors that wouldn’t increase the load with more UI elements (e.g., receiving input or setting up GPU state that doesn’t scale with UI complexity).
我内心的完美主义者仍然不喜欢这样的事实:一个无所事事的GUI会消耗很多时间，但是有很大的好处:当与GUI进行大量交互或调整窗口大小时，它仍然达到400μs！！这使许多现有的保留模式GUI掉了水.尝试调整Spotify，Windows资源管理器，Visual Studio或基本上任何其他桌面应用程序的大小，并查看其反应，以了解我的意思.我的猜测是调整大小时，Spotify在我的PC上会下降到约2 fps.
The perfectionist in me still disliked the fact that a GUI that did nothing was consuming 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 400 μs! This blows many existing retained-mode GUIs out of the water. Try resizing Spotify, Windows Explorer, Visual Studio, or basically any other desktop application, and see how it reacts, to understand what I mean. My guess would be that Spotify goes down to about 2 fps on my PC when resizing.
更改UI基本上是免费的.如果在一帧中显示一百个按钮，然后在下一帧中将它们全部替换为文本框，则性能仍然没有区别.在这种情况下，保留模式的GUI往往会遇到困难.
And changing the UI is basically free. If you display a hundred buttons in one frame, and then replace them all with textboxes in the next, there is still no difference to the performance. Retained-mode GUIs tend to struggle in such scenarios.
另外三个想法:
-
大部分时间都花在了文本渲染上，其余时间几乎无关紧要.如果您想进行大量优化，这将是重点.但是即使优化很少，也可以做到得体.
Most of the time is spent on text rendering, the rest is close to irrelevant. If you want to heavily optimize, this is going to be the thing to focus on. But even with little optimization, it can be made decent.
我怀疑只能通过(甚至根本)通过保留模式和立即模式之间的差异来解释性能上的巨大差异.例如，Spotify将Web堆栈用于UI.肯定会很慢.
I doubt that the vast difference in performance can be explained only—or even at all—by the difference between the retained and immediate modes. For example, Spotify uses a Web stack for UI; that’s bound to be slow.
我猜想，WPF，Win32之类的程序之所以缓慢，是因为它们可以摆脱它，或者因为它们针对与当今使用的硬件完全不同的硬件进行了优化.当然，他们也做得更多，但远远不足以证明两者之间的差异.
I guess, WPF, Win32, and the likes are just slow because they can get away with it, or because they were optimized for completely different hardware than the one we use nowadays. They also do more, of course, but not remotely enough to justify the difference.
我确定您可以制作一个保留模式的GUI，它比我的即时模式的GUI快得多.总的来说，这样做没有什么动力，说实话，这有点令人难过.我喜欢高效的东西.
I’m sure you could make a retained-mode GUI that is a lot faster than my immediate-mode GUI. There is just little incentive for it in general, which is a little sad, to be honest; I like efficient things.
对我来说，主要的收获是: IMGUI很好，您可以快速完成.
The key takeaway for me is: IMGUI is fine, you can make it fast.
由于有几个人问，我决定发表论文.
请注意，您将看到的内容不是公开发布的，并且不超过我个人对公开发布的软件的最低质量期望(这就是为什么我没有在第一时间发布它的原因)地方).因此，请仅将其用于教育目的，而不能用于构建实际的软件.我也不会支持它.
Please be aware that you will be looking at something that was not meant for public release and doesn’t pass my personal lowest quality expectations for a publicly released piece of software (which is why I hadn’t released it in the first place). So please only use it for educational purposes and not for building actual software with it. I won’t be supporting it, either.
下载内容包括论文本身(德语！)，一些针对Windows的预构建可执行文件以及源代码(C ++):
The download includes the thesis itself (in German!), some pre-built executables for Windows, and the source code (in C++):
https://1drv.ms/u/s!AsdZfH5hzKtp9zy1YZtHgeSMApOp?e=/a>
https://1drv.ms/u/s!AsdZfH5hzKtp9zy1YZtHgeSMApOp?e=FbxLUs
玩得开心！
这篇关于与保留模式的GUI相比，使用立即模式的GUI对性能有何影响?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
