Jump to content

  • Log In with Google      Sign In   
  • Create Account


Performance with IMGUI


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 24 January 2013 - 04:34 AM

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?



Sponsor:

#2 Sol_HSA   Members   -  Reputation: 215

Like
1Likes
Like

Posted 24 January 2013 - 08:33 AM

I don't quite see what this has to do with DirectX or XNA, but..

 

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.

It would be exactly the same as with "classic" RMGUI, except that you're generating the list of widgets each frame.


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?

There
are some folk who actually wrote a UI designer that outputs an XML and
then had IMGUI code that renders the widgets based on that data. How far
are they from RMGUI at that point? =)

 

Anyway,
deferred rendering isn't the same as RMGUI; all you're storing are stuff
to render later, not the whole create-message-cleanup you usually need.

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?

 

I've just had a global instance of the IMGUI. Your mileage may vary.

 

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).


http://iki.fi/sol - my schtuphh

#3 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 24 January 2013 - 11:38 AM

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?

#4 MoundS   Members   -  Reputation: 162

Like
1Likes
Like

Posted 18 February 2013 - 11:44 AM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS