问题
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:
What are the performance implications of using an immediate mode GUI compared to a retained mode GUI, when using it for a usual desktop application?
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
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.
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?
回答1:
Since there seems to be some interest in this question still (judging by the views), I thought I might aswell post an update:
I ended up implementing an immediate mode GUI as my masters thesis, and have some numbers in on the performance. The gist is:
Immediate Mode is better/faster in a lot of cases, and worse only in some cases. Overall, it is a completely viable approach to creating a GUI that responds fast and does not drain your battery.
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).
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.
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 more thoughts:
- 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 hard problem. But even with only a little optimization, it's gonna be decent.
- I doubt that the vast performance difference is only or even mostly due to the difference of retained vs. immediate mode. Spotify for example uses a web-stack for UI, thats bound to be slow. 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 PCs than we have now. They also do more, but not remotely enough to justify the difference.
- I am 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 tbh. I like efficient things.
The key takeway for me is: You can make it fast. Don't worry.
来源：https://stackoverflow.com/questions/47444189/immediate-mode-gui-performance