Jump to content
  • Advertisement
Sign in to follow this  
Lord_Evil

How would you speed up your GUI?

This topic is 4238 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, I'm currently examining ways to speed up the rendering of my gui. Up to now I do the following: - each component / ui element has its own vertexbuffer and indexbuffer - if the component's color, size, texture coords are changed, the vertexbuffer is updated correspondingly - rendering a component is done as follows: - apply the current transformation(glPushMatrix(), glTranslatef(...)) - render the ui element (can result in multiple draw calls, e.g. for shape, text, border, ...) - render children if any - restore transformation As you can see, this approach is straightforward but not overly efficient. Now I want to reduce the number of draw calls, texture changes etc. My approach would be: - create one or two "global" vertex buffers, either one for shapes built from triangles and one for text quads or a single vertex buffer that contains both - the vertices are stored in world space - maintain corresponding index buffers - the indices in the index buffer would be sorted by: - Texture - Primitive type (if a single vertex buffer is used and text quads are not replaced by triangles) - visibility (optional, used to group "visible" indices so that indices belonging to currently invisible components could be omitted) Updating would be done this way: - changes of color, texcoord, position (x,y) -> update corresponding vertices - change of position would also require child components to change position - changes of depth (bringing a window to front, for example) -> could require to update all vertices if the window with the highest depth is brought to front (now lowest depth) - changes of texture and visibility would require to resort the index buffer(s) What do you say? Is this a reasonable/feasible approach? Or are there any better solutions? Any ideas are welcome. Thanx in advance. P.S.: I had a look on serveral gui packages on the net, including CEGUI (with and without OGRE rendering) and some of those presented here. What I learned from them is that they either use my current approach (rendering each component individually) or something similar to my proposed approach, i.e. maintaining a vertex buffer / index buffer and resorting if changes occur (OgreCEGUIRenderer for example).

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Lord_Evil
As you can see, this approach is straightforward but not overly efficient.
Now I want to reduce the number of draw calls, texture changes etc.

Well it might not be perfectly efficient, but is it actually slowing you down? GUIs are typically *very* low poly, to the extent that you can often get away with immediate mode. You're much more likely to be limited by fill rate (lot of blending with most GUIs), so all this work rearranging the vertex submission would end up being a waste of time.

Profile first, then optimise. If you have profiled already, then telling us the current bottlenecks would help let you know if what you're doing is suitable.

Share this post


Link to post
Share on other sites
Well, I didn't profile yet so I can't exactly tell. The problem is that I can't exactly tell on how complex the gui will be. You're right, resorting the elements could be time consuming, but since this would only be done in case of a texture or visibility change, such resorting wouldn't be necessary that often.
An compared to the need to submit 100+ draw calls per frame, won't that be faster?

Share this post


Link to post
Share on other sites
Quote:
Original post by Lord_Evil
An compared to the need to submit 100+ draw calls per frame, won't that be faster?

You answered that question already:
Quote:
Well, I didn't profile yet so I can't exactly tell


If you don't know how complex your GUI is going to be, you don't know all the requirements yet. And trying to optimised when you don't actually know what you need (especially when you don't need the speed already) is just going to tie yourself in knots.

Eg. If you ever want to add sub windows or scroll panels you'll probably want to clip sub widgets to the bounds of the window/panel. This is reasonably trivial, but if you've "optimised" your drawing into one big draw call it becomes impossible. You'd either have to undo your drawing optimisations or manually do the clipping yourself (time consuming, error prone).

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
Eg. If you ever want to add sub windows or scroll panels you'll probably want to clip sub widgets to the bounds of the window/panel. This is reasonably trivial, but if you've "optimised" your drawing into one big draw call it becomes impossible. You'd either have to undo your drawing optimisations or manually do the clipping yourself (time consuming, error prone).


That's exactly the point that caused me headaches. I could remove those widgets that are not displayed and add them if visible again, but that would cause frequent resorts. And doing the clipping myself would indeed be very timeconsuming during a scroll.

Thank you for helping me out of this misery ;) From the beginning I doubted my "optimised" rendering would be a real optimization but on the other hand I thought there should be a better solution than immediate mode rendering. So thanx for reassuring me that my current solution isn't that bad.

For the time being I'll stick with my per component rendering approach and try to optimise where appropriate when I know the exact requirements.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!