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

[Andy Sy <an...@ne...>]

Andrew Straw wrote:

 > 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...

Assuming the presence of Mesa might point to one possible
solution... I had the ff. exchange with Brian Paul before:

AS> Does this mean that even if OpenGL app uses a mix of
   > hardware supported and non-harware supported features,
   > instead of defaulting to pure software, Mesa will handle
   > the non-hardware supported portions of the pipeline while
   > the vidcard will still accelerate those portions which
   > it can?

BP> That's basically true.  If, for example, the application
   > uses a 3D texture, the driver will fallback to software
   > while rendering with the 3D texture, and return to hardware
   > rendering whenever possible.

AS> If so, then that's really cool, and will it be possible
   > to have the same behaviour for Window drivers?

BP> I'd expect Windows drivers to do the same thing.