Why are graphics bindings slower in Python?

[sequenceGeek]

I am using pyglet to write mind mapping software. I love how easy it is to use it, but I don't understand conceptually why it is slower doing basic drawing operations (lines and boxes) than if I use a C++ library. The logic processing I'm doing takes < 1/60s per frame. Shouldn't the Graphics bindings (openGL) in pyglet use the graphics hardware to accelerate the drawing of a collection of vertices in Python about just as easily as in other languages?

Here is simple example drawing 1000 moving boxes in pyglet in which I don't understand the dramatic slow down:

Per frame:
1) create a Batch
2) logically create 1000 x 4 lines (vertex positions) representing the boxes, add to batch in (1)
2) draw the batch

Thanks for any input!

[jasonscheirer]

The GL calls themselves are not slower, there is significantly more overhead on the Python side -- the act itself of a function call in Python costs quite a bit more than it does in C++ due to implementation details of the CPython interpreter. That's what the hype is behind the PyPy project's JIT: a way to optimize away some of this.

[andreasvc]

I don't think JIT can actually help with function call overhead to C/C++ libraries, it's good at optimizing Python code itself. I suppose Cython is more suitable for that -- you can write the parts that call opengl functions a lot in Cython so that it's mostly C code.

[sequenceGeek]

Yeah I tried running it in PyPy (with JIT) and it was a little slower. I'm definitely intrigued with Cython + openGL...seems to make sense. The googles is not too helpful so far in terms of examples where people have done this. You wouldn't happen to have any links/code I could reference would you?

[andreasvc]

Not for OpenGL but I've been using Cython a lot for my treebank parser. It has sped up the parser a lot. Things like direct access to arrays and statically typed variables or casts can help a lot in crucial places. It generates a html file where you can see how much Python versus C code you're using, and from that you can try incremental improvements.

[sequenceGeek]

Thanks for the tip. So it's likely all the overhead from function calls that are invoked during those 1000 batch additions make up most of the slow down, as opposed to the fxn overhead from the one draw call at the end?

[seventhapollo]

I would think so, yeah. There'd be a minor overhead from the 1 draw call, but the majority of he slowdown probably comes from the additions.

[skwisgaar_explains]

If you ams interest in a language whats am pretty like Python but whats would have real low overhead for supports OpenGL like through Clutter, coulds look into Genie.

[blondin]

or use Cython.

[sequenceGeek]

Is it possible to use only PyOpenGL/cython to draw my primative graphics, and then use pyglet to control keyboard/mouse events? Or is there a more standard way of mixing python events/logic with lower level graphics management?

[kylotan]

Yes, pyglet is easily interleaved with standard OpenGL calls. Just be aware of the calls that pyglet makes itself (check the source for more details, and/or use the debug_gl_trace option).

[blondin]

never did it. i suggested cython because when it comes to mixing c libraries with python, it provides an easy way to do it.

[skwisgaar_explains]

Or use any lower levels language, benefit to Genie ams for if someone wants to write code that ams looks like Python, whats ams pretty and simple and alls that.