Hi

For those of you who know what IMGUI is, you know that it can be implemented as is or defferred.

That is, you call a "DoButton" which will draw the button and return true if it was clicked such that you can if(DoButton){logic}.

Now, since this implementation requires that you actually draw the button where you call this function, the IMGUI class would have to carry with it a render texture and a pointer to the device.

How would it impact performance to render let's say 100 GUI widgets all throughout the application? This means a drawcall scattered around in a 100 places.

Another option, defferred rendering requires you to save alot of widget information which will be drawn later together. This sort of undermines the IMGUI concept aswell. Is this something to consider?

Lastly I have a question regarding passing the GUI interface around in code with IMGUI. Since you need to be able to draw a widget from any part of the code, what implementation should I go for? Should the GUI class have a global instance? Singleton? Or just pass the GUI interface to every function in the code?

How
would it impact performance to render let's say 100 GUI widgets all
throughout the application? This means a drawcall scattered around in a
100 places.

Are you planning to create buttons at random times during the update? Better to have a RunGui() function at the application level, similar to Update() or Render(), which calls into sub-systems. You can also pass the GUI object as a parameter, avoiding a singleton or global.

Another
option, defferred rendering requires you to save alot of widget
information which will be drawn later together. This sort of undermines
the IMGUI concept aswell. Is this something to consider?

Buffering vertices is a common way to render in 2D anyway. The rendering method is irrelevant to the IMGUI concept.

Oh,
and IMGUI is not a silver bullet. It makes simple things very simple,
but complex things become very, very complex. In RMGUI, all things tend
to be about as difficult (with complex things being somewhat more
complex than the simple things, but not much).

What do you mean by complex? Interactions between the user code and the GUI are almost always simpler in IMGUI, because when you are generating the GUI on the fly it's very clear how to modify it.

Layout is a bit more tricky with IMGUI, because it lacks information until the frame is complete.

Or do you mean complex widget types? Do you have an example?

What do you mean by complex? Interactions between the user code and the GUI are almost always simpler in IMGUI, because when you are generating the GUI on the fly it's very clear how to modify it.

Layout is a bit more tricky with IMGUI, because it lacks information until the frame is complete.

Or do you mean complex widget types? Do you have an example?

I think Sol is talking about the complexity of the library code, not the application code. A very simple IMGUI library isn't much more than an immediate mode rendering library with some fancy mouse logic, so it's very simple to implement. However, an IMGUI library with a realistic set of features (including layout) will be much more complex to implement than the equivalent RMGUI library.

When it comes to application code complexity, IMGUI of course scales much better than RMGUI. This is the payoff for investing the extra effort in the library.