On 11/6/08, swiftcoder <[EMAIL PROTECTED]> wrote: > > On Nov 4, 4:37 am, Jonathan Hartley <[EMAIL PROTECTED]> wrote: > > > This may or may not prove to be significant for you, but I found > > better performance on my hardware using batches of indexed > > GL_TRIANGLES, rather than GL_TRIANGLE_STRIPS or GL_TRIANGLE_FANS. I > > didn't try GL_QUADS though. > > Quads are typically not optimised in modern cards/drivers, so > triangles generally win. Triangle strips should still be faster than > triangle lists, but only if the strips are also indexed - unindexed > primitives can't utilise the GPU's vertex cache.
This advice is actually a little out of date -- modern cards _do_ optimize quads, and will render (indexed or unindexed) triangle lists faster than strips. But you're unlikely to see these gains in a pyglet application because... > > > The fewer batches you can render, the better - so if your cubes don't > > move or rotate independently of each other, then rendering them all in > > a single batch object will be much faster. > > Multiple draw calls are relatively inexpensive, but state changes are > expensive. Rendering 2 cubes in 1 or 2 draw calls shouldn't make much > difference, but binding a different texture, shader or vertex buffer > between the calls will cause a significant performance hit. This is true if you're programming in C/C++, but the performance overhead of a foreign function call (from Python to OpenGL) usually far outweighs the cost of a state change, so they're equally inefficient. Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
