Re: [PyOpenGL-Devel] pyopengl extension detection.

[Roman V. <red...@gm...>]

Hello, Mike.


Here is a preview of patch for platform-specific extensions. It supports
only GLX platform,
since I want to get your review of my design decisions. Once it will be
done, I will update
the patch with WGL support and put stubs for other platforms.

So, each platform implementation should provide 'getExtensionsString'
method to list
available platform-specific extensions in space-separated string. Both, GLX
and WGL
ways provide this list in this form.

In case of GLX implementation definition of method is surrounded with
try-except
block, because code tries to import 'glXQueryExtensionsString' and
'glXGetCurrentDisplay'
functions from GL-dll and according to spec these functions are defined in
version
1.1 and 1.2 of GLX-spec respectively.

Thus in case GLX implementation doesn't provide a method for querying
extensions,
code will define a method returning empty string. Non-extensible and stub
platforms
should do the same.

Next, base platform implementation defines 'hasPlatformExtension' method
which
acts like 'extensions.hasGLExtension' function except it won't perform
logging. I was
trying to avoid platform-specific code and circular dependencies with
'OpenGL.platform'
in 'OpenGL.extensions' module, thus all code resides in 'OpenGL.platform'
sub-package.
However, cached 'contextdata' for 'GL_EXTENSIONS' will also be used for
platform-specific extensions.

Once notable difference between 'hasGLExtension' and 'hasPlatformExtension'
is that
buffer for extensions list is by default initialized with 'None' to
distinguish with '[]' which
means no extensions available.

In addition, I've removed one of calls to 'checkExtension' in
'constructFunction' method,
because it seems redundant for me. Fix me, if I wrong.


Best Regards, Roman.



On Mon, Nov 4, 2013 at 8:46 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> 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
>
>