I did some profiling the other day and I found that drawing my gui over my 3d scene increased my frametime by up to 30%. I'm using GWEN for my gui but it allows you to write a custom renderer which I did. I used the same terrible techniques as the sample renderer but was able to squeeze out a little more performance by better integrating it into my engine which removed a few OpenGL calls. The problem with the renderer is that the way it works is that I basically get to derive a renderer class and rewrite a DrawTexturedRect function and that is the only way I can get geometry. In the sample implementation (and mine) It places two triangles to form a quad in a buffer on the cpu side when everything is finished drawing or the buffer is full it calls a flush function which uploads the buffer to the gpu and draws it, then the buffer is emptied. The problem is that this happens every frame and I have no way of knowing whether the geometry has actually changed between frames so I have no choice but to do everything all over again. So I was thinking of ways to change this awful setup while only being allowed to use DrawTexturedRect and I thought about instancing a single 1x1 quad (everthing is a quad with the same texcoords) and then scaling and translating it in the vertex shader. But unfortunately instanced rendering is only core in OpenGL 3.1+ and my minimum is GL 2.1 support where it is available as an extension (but probably not on intel cards). So my question boils down to is it faster to draw individual quads (one draw call per quad) that are already in the gpu memory or to use the terrible buffering solution? any other general GUI drawing advice would be appreciated as well.

Gwen apparently supports caching (take a look at the ICacheToTexture interface in the base renderer). Unfortunately I haven't tried to implement it yet so I can't say anything about its usefulness.

Gwen apparently supports caching (take a look at the ICacheToTexture interface in the base renderer). Unfortunately I haven't tried to implement it yet so I can't say anything about its usefulness.

Hmm thats very interesting. Depending on how it works that may be ideal. Unfortunately none of the samples seem to use it.

This waiting (draw other things, then draw GUI) might waste some parallelism.

Do you need normal 3D scene drawing while there is a dialog in front of it? A freeze frame (copy last frame to a texture, then draw it as a full-screen quad) should be cheaper.

Unfortunately the 3D scene must remain dynamic while gui elements are being displayed.

I dunno if it's optimal how I have my stuff set up, but I have a simple sprite batching class that I use to draw quads with. I don't really do anything special at all.

SpriteBatch manages the state, etc. It's really dead simple and really doesn't do that much work internally. Just tracking a few things, starting a new batch, finally issuing the draw call, etc. I pre-fill the index buffer and cap how large batches can get. Adding a sprite to the batch just needs a Rect for the position and another for the texture coordinates.

A batch is a simple struct like this

struct Batch
{
	Vertex2D*	verts;
	Texture*	texture;
	u32		numSprites;
	u32		numVerts;
	u32		numIndicies;
}; 

Then keep a vector of them. Batches hang around until you explicitly purge them, so once you add a bunch of quads, you don't need to re-add them and the only thing that needs to happen is the draw call (and prior memcpy() to push whatever batch verts to the underlying vertex buffer).

It's not fancy or super robust, but I don't see why I couldn't draw an entire UI with just one or two draw calls. Drawing thousands of textured quads costs practically nothing, and my framerate is still well into the thousands. What's GWEN doing that's taking so long?