Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andrew S. <str...@as...>]

I wrote a similar email about this some months ago. Some elements of the 
conversation:

Mike Fletcher responded that there's probably some unacceptable overhead 
with ctypes.  Part of the problem is mapping the versioning from C to 
Python.

In C, there are both compile-time and runtime versioning considerations: 
the headers you compile against may define certain functions that aren't 
available until a certain runtime version, so you'd better check before 
using them.  As the current package is built in Python, I think we have 
the lowest-common-denominator situation, where we basically assume only 
OpenGL 1.1 headers and thereby limit usage of any of the newer 
features.  Consequently, no runtime version checking seems to be 
required in general.  With the dynamic nature of Python, we could of 
course do something fancy that only exposes the functions and constants 
available for a certain version of OpenGL, but this may end up causing 
unnecessary confusion.  To expose recent OpenGL features in PyOpenGL, we 
have to consider what to do in the situation where someone with, say, 
OpenGL 1.4 headers compiles PyOpenGL to run on a maching with only  
OpenGL 1.1 libraries.  Maybe there is an elegant solution to this problem...

If someone (I don't have the time) embarks on a rewrite of PyOpenGL, 
that person may want to consider pyrex instead of SWIG.  Interesting tip 
about the ruby/OpenGL interface -- I'll have a look at that.

Cheers!
Andrew

Andy Sy wrote:

> I've noticed that PyOpenGL has lagged behind the latest
> OpenGL versions for sometime now.  Is the complexity of
> SWIG to blame for this?
>
> Would a different approach, say ctypes
> (http://starship.python.net/crew/theller/ctypes/) or use
> of the Python C API actually make things easier?
>
> I took a look at Ruby's OpenGL interface (
> http://www2.giganet.net/~yoshi/ ), and
> interestingly, there's not much acrobatics that
> need to be done.  There's a single 4,252 line C source
> with a seemingly very simple way of wrapping C
> OpenGL calls and that's it. (Could Ruby's C interface
> really be that clean?!?)
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users