Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Lorenzo M. <lma...@de...>]

Mike C. Fletcher wrote:

> If you have a PyOpenGL code-base you should be 
> looking at reworking the code in order to eliminate the use of "legacy" 
> APIs before OpenGL 3.1 drivers become mainstream.

This seems to be OpenGL's direction indeed:

Appendix F "Version 3.0 and Before", page 301
Appendix G "Version 3.1", page 308
http://www.opengl.org/registry/doc/glspec31.20090324.pdf


But it was my understanding that even when OpenGL 3.1 drivers become 
mainstream, to obtain a "forward-compatible" 3.x context you will have 
to explicitly request it, otherwise you will get a 2.x legacy context.

See for example this patch to allow an application to choose between 2.x 
and 3.x context creation, recently committed in SDL trunk:

http://www.nabble.com/OpenGL-3.0-Context-Creation-td22645797.html


Also, when you are using a 3.x context and your vendor chose to 
implement the GL_ARB_compatibility extension, you can find there all the 
constants and functions deprecated in 3.0 and removed in 3.1.


So it seems to me that allowing any existing PyOpenGL legacy app to 
continue running on OpenGL 3.1 is unlikely to require changes to the 
code-base, because:

  * if your driver still supports creating a 2.x context, nothing changes;
  * if your driver only supports creating a 3.x context, but implements 
the GL_ARB_compatibility, PyOpenGL extension mechanisms will 
automatically detect it and expose all constants and functions which it 
declares.


To sum it up, it looks like legacy PyOpenGL apps will be out of luck 
only if a vendor releases a driver which doesn't allow 2.x contexts 
creation *and* doesn't implement GL_ARB_compatibility extension.  Does 
any of this make sense?


Also see this document from nVidia about how they chose to implement 
OpenGL 3.x: http://developer.nvidia.com/object/opengl_3_driver.html

-- 
Lorenzo Mancini