Re: Help with ARB Extensions on Windows for PyOpenGL 3.0.0a5?

"Mike C. Fletcher" <[email protected]>
Newsgroups gmane.comp.python.opengl.user,gmane.comp.python.opengl.devel
Message-ID <[email protected]>
Mike C. Fletcher wrote:
...
> 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.
>   

PyOpenGL 3.x CVS now has what appears to be a fix for this.  Basically 
if there is a NULL pointer for an extension then every time you try to 
call it, before raising the error it checks to see if the function is 
available in the current context, if so, it loads the function and then 
substitutes the __call__ method for the function's call with a 
staticmethod wrapper (C-coded, so should be moderately fast).

There is still a performance penalty, but it should make most operations 
fairly intuitive.  The biggest problem it introduces is that any wrapper 
code that checks for the boolean truth of an extension function to "see 
if it is available" is going to think it's not available.  That's pretty 
sub-optimal IMO.  Just don't have an elegant solution to it yet.

Have fun,
Mike

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.