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