Re: [PyOpenGL-Users] Help with ARB Extensions on Windows for PyOpenGL 3.0.0a5?

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

zaltor wrote:
> I'm having a bit of a problem loading extensions under Windows and I'm 
> wondering if I'm understanding the semantics of extension modules 
> correctly.
>
> If I run the following snippet (modeled after the sample extension 
> snippet in the PyOpenGL for OpenGL Programmers page)
...
> on Python 2.5, I get the following result:
>
> <OpenGL.platform.glCreateProgramObjectARB object at 0x00F77EB0>
> False
>
> It seems that PyOpenGL is not finding 
> the function pointers for the extension functions.  Digging through the raw 
> and platform directories, it seems that function pointers are found using
> wglGetProcAddress, which, according to the MSDN, returns a OpenGL 
> context-dependent pointer.  Specifically:
>
>     When no current rendering context exists or the function fails, 
> the return value is NULL.
>
> Hence, I modified my snippet to the following, by moving the import of 
> the ARB extension module to after I have a context:
Urgh.  Well, I guess that explains the weird code and the "init" 
functions for the extensions.  Going to have to fix that at the PyOpenGL 
level.  Grr.  If it's really context-dependent we're going to have to 
run an extra function for every extension function (since you can have 
multiple contexts) :( .  Wow, that's a sub-optimal design.  Someone 
should yell at the MS programmers.  Oh well, Windows, what are you going 
to do.

Ah, if I'm implying correctly from the wglGetProcAddress "man page", 
it's actually just that the function might not be available on *this* 
context, so we just have to delay resolution until the first call (or 
more realistically, do a check for NULL function pointer and if NULL do 
a wglGetProcAddress to see if we can get a non-null pointer before 
raising the "function is null" error).  Will require that the "null 
function pointer" objects be capable of replacing themselves (somehow) 
with the extension function... but then the normal import mechanism 
pulls them from the module directly... bah.  Don't want the overhead of 
an extra Python function call just to allow for late loading on windows, 
we want the raw ctypes function pointers whereever possible (for 
speed).  This is going to be a PITA one way or another.  Oh well.

Thanks for the report, I'll try to look into it this weekend.

Have fun,
Mike

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