Re: pyopengl extension detection.

On 11/02/2013 10:11 AM, Roman Valov wrote:
> Ok, Mike.. the actual question to you is in last paragraph.
>
>
> Here is update with my review of the problem with wglSwapIntervalEXT 
> and wglGetSwapIntervalEXT.
> Seems that problem is driven by two diffrent factors:
>
> 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter 
> for 'createBaseFunction'.
>
> Thus OpenGL/platform/baseplatform.py code tries to load extension 
> functions from platform.GL library
> which actually doesn't have them in common case and as a result I've 
> got these functions unresolved.
>
> 2) BasePlatform.checkExtension code relies only on 
> glGetString(GL_EXTENSIONS).
>
> I've tested extension WGL_EXT_swap_control on NV and Intel gpu 
> platforms. In fact only
> on NV platform this extension was listed in glGetString(GL_EXTENSIONS) 
> result. According
> to specs:
>
> http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt
> http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt
> http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions
>
> one would to use wglGetExtensionsStringXXX to check for WGL 
> extensions. On both platforms I've used
> required extension was listed in wglGetGetExtensionsString output. As 
> I see on GLX there is similar
> functionality provided by glXQueryExtensionsString. Which also aren't 
> taken into account in PyOpenGL.
>
>
>
> So, my plan is firstly to fix gengl.py and later add method for 
> platform-specific extensions check.
> But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py 
> that is commited to bzr.
> Besides header file path in comments (which is minor issue), I see 
> whitespaces differences and
> moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. 
> Could you say anything
> about that symbol? Was it added by hand or was it included in previous 
> versions of wglext.h?


gengl.py was probably last run many years ago now, and the versions of 
the underlying libraries you're using (basically pyglet) are likely 
different than the ones I used way back then.  GLAPI is basically a 
macro that marks a function for DLL export, it *shouldn't* affect 
anything in our wrappers.

Note that I'm about 50% of the way through an API generator based on the 
Khronos XML API spec, i.e. generating the wrappers from the thing that 
defines these APIs formally (and which is used to generate the headers 
that gengl and get_gl_extensions are parsing). That *should* generate 
all of WGL, GLX, EGL, GL, and GLES in full, and should keep them 
up-to-date going forward in a robust and maintainable fashion.  I'll 
integrate your changes for wglGetExtensionsString and 
glXQueryExtensionsString when I get to the point of generating the WGL, 
GLX and EGL wrappers from the specs. The new generators won't actually 
alter the support code (e.g. platform), so a patch to those *should* 
carry across.

I *wouldn't* suggest spending much time on fixing gengl.py based 
generation, because it has always proven rather fragile (which is why I 
don't use it for the core), even if it were working today, I'm unlikely 
to keep using it if I can use the XML registry to generate the functions.

The WGL, GLX and the like extensions will be declared in the same manner 
as the GL ones, so you'll get the "extension" parameter set properly 
when regenerated.

Hope that helps,
Mike


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net