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

[Mike C. F. <mcf...@vr...>]

Lorenzo Mancini wrote:
> 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.
That assumes that your driver has the ability to create a legacy 
context.  While nVidia might be committing to always have a legacy 
context available, the OpenGL 3.1 spec doesn't require having a legacy 
context available.
> 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.
Yes, again, with the assumption that your vendor is supporting that 
extension.  With nVidia supporting it we can assume ATI/AMD will likely 
support it as well... which just eliminated any significant benefits 
from the OpenGL 3.1 rewrite :) .

> 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?
No, that's the scope of it, but the question arises: why define 
deprecations at all if no-one is intending to drop the deprecated 
features?  That is, the whole point of the deprecations was to create a 
smaller, lighter, more flexible API that could be more readily 
maintained and extended; something that could compete with DirectX 
head-to-head in games (where there's some really big money).  In the 
OpenGL 3.0 era, we were basically told, "it's changing suck it up", but 
there was a heck of a lot of blow-back from CAD and similar users, while 
the Game users considered it too little too late.

So now we have an extension which re-enables all of the legacy paths, so 
requires all of the complexity 3.1 was supposed to eliminate to be 
present... great for people with legacy code, but unlikely to let OpenGL 
"win" in the games sphere.  Then again, there's not a lot of OpenGL 
games left, so maybe that's not really a concern and the ARB is 
effectively just acknowledging that their remaining community values 
compatibility far more than gaming competitiveness.  Hopefully nVidia 
will implement with the switch with something like a separate legacy 
driver that will let them  do a Longs-Peak-style driver for game 
competitiveness while swapping in a (separate) legacy driver only when 
requested.

Anyway, yes, PyOpenGL will be supporting GL_ARB_compatibility, so if 
your driver supports it, you should be able to use the legacy APIs.  So 
the advice that you will need to recode is probably invalid for most 
users.  (And I apologize, while the 3.1 spec came out a few days before 
PyOpenGL 3.0.0 I hadn't had a chance to read it at the time I wrote the 
release notes).

Have fun,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com