On Sat, Dec 4, 2010 at 5:49 PM, Ian Mallett
<geometrian@xxxxxxxxx> wrote:
Buffer binding is one of the slowest GL calls you can do, short of transferring huge chunks of data around (glTexImage2D, glReadPixels, etc.). State changing is one of the worst things you can do for efficiency, especially on top of a scripting language where the overhead is much higher. You have 40 sprites, each with 3 VBO bindings, and 5 texture bindings. If I'm understanding right, that's 120 VBO bindings and 200 texture bindings! Transferring this data across the bus once (when you put it in a display list) will speed things up greatly, but you'll notice that the framerate in 6 is still much lower than in 2 or 4.
If you're just drawing sprites, chances are you don't need very many textures. At the very least, you can use a texture atlas, or batch calls by the texture required.
I don't know exactly the situation you're in here, but unless the 40 sprites all have different geometry, you need only bind the data once, and then call glDrawArrays 40 times.
In general, try to minimize binding calls, such as glUseShader, glBindFramebuffer, glBindTexture, and glBindBuffer.
Yeah, that makes a lot of sense. I'm not sure how I could implement this advice in the standalone OBJ loader without imposing a lot of restrictions on how it could be used. For instance, I can see how you might make it more efficient when the sprites are sorted by the texture required. But I can't see how to do that and also make it so it doesn't break horribly if the sprites are unsorted. I'll think about it, but for now I might stick with the display lists.
My test is not precise enough to worry about the difference between 113fps and 121fps. I think based on the test that method #6 is effectively as fast as #4. I may try to squeeze a few more frames per second out, in which case I'll make a more controlled test, but mostly I was interested in getting the three-order-of-magnitude speedup in loading that you see between #2 and #4/6.
-Christopher