On 10-11-18 08:14 PM, Jonathan Hartley wrote:
> Hey folks.
> I'm finding pyglet's OpenGL bindings give me at least 2 times faster
> framerates than PyOpenGL's. This ratio is surprisingly high to me, am I
> right to be surprised?
I'd probably expect around 1.5x at least, and 2x doesn't surprise *me*
:) . Pyglet doesn't, AFAIK do any pointer-reference interception, so
their ctypes calls are direct-to-C, while PyOpenGL is doing a *lot* of
Python code for every array-handling call. Even when that code is
translated to Cython, it is still a lot of machinery involved compared
to passing a ctypes pointer for everything.
> I'm probably doing lots wrong - I don't really know what I'm doing.
> Here's what I've checked. What else should I be thinking about?
> I'm setting ERROR_CHECKING=False
> If I run with FULL_LOGGING then I see no extra GL calls to retrieve
> status values.
> I tried running with ERROR_ON_COPY=True, no errors are reported
> I'm running Python with -O.
ERROR_CHECKING = False
CONTEXT_CHECKING = False
STORE_POINTERS = False
FULL_LOGGING = False
ALLOW_NUMPY_SCALARS = False
would be the settings to disable as much of the machinery as possible,
but even with that, we're still doing more code than Pyglet for each
array call. I'd still expect around 1.5x run-time for PyOpenGL vs.
Pyglet on the kind of code you're writing (lots of calls, a "classic"
To get real performance improvements, vertices into a single numpy
array, put your matrices into another array, multiply matrices *
vertices and draw with a single call from an index array across a VBO.
If you're updating matrices on each call, use a shader and do the
multiply on the video-card (with a streaming VBO for the matrices and a
static one for the points). The overhead of pointer calls gets
amortized as you get larger and larger arrays in PyOpenGL, so it tends
to favour the modern VBO + shader model rather than the older classic
Mike C. Fletcher
Designer, VR Plumber, Coder