Why ctypes for OpenGL? (Since Brian asked...)


Brian asked me to explain what benefits I'm expecting from a ctypes version of OpenGL versus the PyOpenGLSWIG version. So, why not post it where everyone can read it (if one person asks, probably 10 want to know)...

   * Easier compilation/more robust operation
o Probably 90% of our time in PyOpenGLSWIG is spent on
compilation issues
+ What few pieces of C code we'll need are going to be
simple and straightforward, easily debugged and then
forgotten, effectively we have a few pieces of code to
do those things that are either a serious pain in
ctypes or need C-level speed to be practical... and we
only decide which pieces those are with real-world
data saying "yes, that's the problem"
o We piggy-back on ctypes/libffi porting, let them deal with the
bulk of the cross-platform issues and the complex compilation
issues and we just need to be able to find the OpenGL DLLs and
pull entry points out of them.
* Lower barrier to entry for users to hack on the system and become
developers
o Instead of an expanding macro system (SWIG) that matches via
unseen rules and can only be debugged by spelunking through
the final generated code, we get a system where you get a
traceback showing exactly what we were trying to do
+ Extension modules will just import the services they
need and use them, they won't have macro
comments that interact with a funky-hacked distutils
script to decide which versions to build
o Make it possible to hack on new (extension) modules for the
system without requiring a long compile-test cycle (which
kills my productivity when developing new modules)
o Reduce the number of languages a user needs to know to
develop PyOpenGL
+ Comes right down to it, I have so little time to work
on PyOpenGL that I really need to get to the point
where other people can do the work. Everyone who
wants to use PyOpenGL knows Python, only a fraction
know C...
* Flexibility
o Make it possible to hook into the wrapping aspects of the system
+ e.g. register a handler for a data-type (e.g. a PyGame
surface, or a PyMedia data-stream) such that it can be
efficiently handled as a texture/array data-type
o Make it easily possible to include modules to which I don't
have access (really this is more of a "lower barrier to
entry" thing, but it means that people who have a 2.0 GL.h
header can provide 2.0 features without needing them to be
present on the machine compiling a binary distribution)
+ We can actually just try to find the entry point, and
if we don't, just catch the error... avoids lots of
"if opengl version > XXX" code
o Ready for PyPy when it matures (i.e. move the code up into
Python with as little C code as possible)
* Cleaner design (hopefully)
o Tarn's design was heavily influenced by SWIG's
macro-expansion philosophy... it's a little hard for people
to follow, even when they've been working on it as long as I
have. It's elegant in many ways, but it's also a pretty
serious PITA for maintenance. And in the end, I just don't
*like* massively-nested macro-expansions!
o Eliminate the complex and fragile compilation scripts; have
2 or 3 extensions, something to kick off the Togl
compilation (assuming we still distribute it (likely)) and a
big block of Python packages that just get copied over
unchanged.

And there you have it, a quick explanation of why it's at least worthwhile to try building OpenGL-ctypes IMO. Oh, apologies for the formatting, I didn't think to post this until after Thunderbird had converted it into plain-text, and I don't really have time to reformat it this afternoon.

Comments

  1. Matt

    Matt on 08/19/2005 7:25 a.m. #


    I'm glad to see this. After fighting around with trying to build PyOpenGL on Fedora Core 1 (unsuccessfully (it's the first time I've seen a build script get into an infinite loop), but it's OK since I have a working version on win32), I'm happy to vote in favor of a simpler build.

  2. Rene

    Rene on 08/23/2005 3:07 a.m. #


    Also speed of loading, and download size.<br />
    <br />
    When I did a prototype it was possible with ctypes to have a much smaller installed size. As well as a faster loading time.<br />
    <br />
    I'm so glad you're working on ctypes pyopengl! It looks like you're getting quite the way through as well :)

Comments are closed.

Pingbacks

Pingbacks are closed.