Re: setting OpenGL.ERROR_CHECKING to F alse has strange consequence on function loading

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> 
> On 02/18/2014 03:44 PM, rndblnch wrote:
> > hello again,
> >
> > while moving some code to core profile, i found a strange interaction
> > between the OpenGL.ERROR_CHECKING flag and the function loading mechanism.
> > the following program (MacOSX specific for the glut core profile flag)
> > prints True if error checking is enabled and prints False otherwise.

> I haven't been able to duplicate it here (i.e. it always returns true on 
> a Linux amd box).  My guess is that we are seeing an error from earlier 
> in the process startup being interpreted as "function doesn't exist" 
> when loading that function, but I can't see *how* that would occur, as 
> the actual code to get the entry point shouldn't care about OpenGL errors.

yes, it looks like it is Mac OS X specific.
i think i begin to understand where it comes from.
in OpenGL.GL.VERSION.GL_3_0, the version of the functions imported by:
from OpenGL.raw.GL.VERSION.GL_3_0 import * (line 15)
can be replaced by later imports from ARB, e.g.:
from OpenGL.GL.ARB.vertex_array_object import * (line 28)

but on the mac, this specific extension is not present, apple provides
instead the GL_APPLE_vertex_array_object extension.

what i do not understand however, is how the error checking interact with
those import (i.e. why setting error checking makes the ARB import find a
valid glGenVertexArrays function and why it becomes invalid when error
checking is disabled).

renaud

> 
> Sorry to not be much help here,
> Mike
> 





------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net