As I understand it, the pyglet docs are referring to all the members of pyglet.gl, which are automatically generated python bindings to all the OpenGL functions. They are not necessarily the most convenient, Pythonic or efficient ways you could imagine calling OpenGL from Python. They are mostly intended for internal use by the rest of pyglet, although there's no harm in using them yourself too.
However, the real intent is for you to use the alternative functions that pyglet provides, under pyglet.graphics, and sprites (everything NOT in pyglet.gl.) These are designed to be both convenient to use, and super fast. For example, pyglet.graphics.batch as josch mentions, uses OpenGL's super-fast vertex arrays stored in vertex buffer objects, without us having to worry about that underlying details *too* much. On Nov 4, 4:02 pm, Lunpa <[EMAIL PROTECTED]> wrote: > Interesting. I'm looking at the 'graphics' section in the programing > guide and it says this: "using the OpenGL interface directly for > drawing graphics is difficult and inefficient". Why is that? (and is > there a better one to use?) > > On Nov 4, 3: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. > > > 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. > > > On Nov 4, 5:34 am, Lunpa <[EMAIL PROTECTED]> wrote: > > > > I've been teaching myself opengl recently, and I've hit a wall, which > > > is what to do with bottlenecks, or let alone, figure out what is > > > causing them. > > > > I wrote a short program (based off of the pyglet "hene" port of the > > > nehe lesson1 base case) to illustrate what is vexing me, or atleast as > > > best as I can pin it down; > > > > I have a function called "call", which is called from the on_draw > > > event of the window, and the function contains the following code: > > > > def call(self): > > > if not self.__compiled: > > > glNewList(self.__dl, GL_COMPILE) > > > > r = 5 > > > ci = 0 > > > span = range(r*-4, (r*4)+1, 4) > > > for x in span: > > > for y in span: > > > draw_cube(x, 0, y, ci) > > > ci +=1 > > > if ci > 1: > > > ci = 0 > > > glEndList() > > > self.__compiled = True > > > > glCallList(self.__dl) > > > > the "draw_cube" function just calls a glBegin(GL_QUADS), 24 > > > glVertex3f's, and the glEnd() > > > > When I run this program with just the basecode (eg, I have the call > > > function commented out), > > > the thing can do well over 60 fps (spikes over 100, sporadically). > > > > When I have the function in the code, the code plummets to an average > > > of 20fps. > > > > What do I need to do to be able to draw more than a handful of > > > polygons without dramatic slowdowns??? > > > > ps: my gpu is an intel 945gm; not exactly a powerhouse, but the code > > > has been tested on other machines with similar results. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
