On Sat, Dec 4, 2010 at 5:49 PM, Ian Mallett <[email protected]> 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

Reply via email to