🔒 Locked 🎮 Unity

Batched GUI methodology

Started by sipickles Apr 13, 2006 at 3:33 PM 4 replies 750+ views

Original Post

Apr 13, 2006 at 3:33 PM

Hi, (Seems to be a lot of GUI threads at the mo, so here's another!) I am trying to write my GUI so that I am batching the drawing. Instead of each GUI element being rendered each frame, I am attempting to batch together the rendering, reducing overall load. Each floating window is first marked as dirty when the app starts. During update(), they render themselves and their children to a section of a RENDERTARGET texture (shared with other GUI windows). They are then marked as clean. During render(), the shared texture is used as the source texture for all the windows. If any of the windows are updated, they are marked as dirty, and only those will be updated on the next frame. I am considering only allowing updates every nth frame (with n being the largest value I can get away with without lag being apparent!) Does this approach sound worthwhile? It seems the RENDERTARGET textures will be locked and unlocked a lot, is this any better than just rendering to screen? Thanks for your advice! Simon

Koshmaar

Apr 13, 2006 at 3:58 PM

What rendering API are you using? If it's OpenGL or DirectX, then IMHO it's not worthwile, you'll just lose time for pre-mature optimization.

However, if you're using software rendering API (like GDI, SDL or Allegro) then using this dirty rectangles approach may prove to be very good design decision.

sipickles

Apr 13, 2006 at 4:04 PM

This is a DX9 GUI.

I posted on GD.net before, and had a couple of people relate that by batching the GUI graphics like this, they achieved significant performance benefits. I was just wondering if my approach was okay?

My previous method just used a single texture containing all the GUI graphics, then a parent/child structure, which recursively filled a single dynamic vertex buffer EACH FRAME.

That doesnt sound that efficient, when only a tiny proportion of the GUI will change each frame?

Si

Extrarius

Apr 13, 2006 at 4:40 PM

Quote:
Original post by sipickles
[...]That doesnt sound that efficient[...]

It's more efficient to have and use something that works well enough than it is to spend time optimizing something that already works well enough.

If you haven't benchmarked it and actually measured that it was taking too much time/processing/etc, then you don't need to worry about it.

Programmer16

Apr 13, 2006 at 6:25 PM

I'm currently working on this too, so I figured I'd tell you my idea.

What I've been using -
Each widget contains 6 vertices (a quad). These values are updated when one of the set type functions are called (I have a fucntion called UpdateVertices(). It gets called when Move(), MoveRel(), Resize(), or SetState() is called.)

Then I have a manager class that stores all of the widgets in a std::vector. Each frame, I create a vertexbuffer (length is equal to m_Widgets.size() * 6 * Vertex::SIZE.) After locking, I loop through and copy the vertices:

for(int nIndex = 0; nIndex < m_Widgets.size(); ++nIndex){    memcpy(&pVertices[nIndex * 6], m_Widgets.at(nIndex).GetVertices(), Vertex::SIZE * 6);}

This does require that your system supports a z-buffer style system (since it draws the font after all of the widgets) or that your font be included in the same texture (I chose the latter, since it was simpler and more efficient.)

This works really well and doesn't seem to be too slow.

HTH!

sipickles

Apr 14, 2006 at 2:44 AM

Okay thanks,

I will go the simpler route! My font is part of my GUI texture already so will help!

Thank you

Simon

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.