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:
What are the performance implications of using an immediate-mode GUI compared to a retained-mode GUI, when using it for a typical desktop application?
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:
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 it mean that I have one more frame of input lag over a retained-mode GUI?