On 11/08/2013 09:13 AM, Roman Valov wrote:
Hello, Mike.

Hi Roman,

I'm afraid I've rather hacked up your patch as I made it fit into the xml generation branch. The biggest changes made:

That's rather more changes than I was intending, but hopefully it makes the result cleaner (e.g. there's just one entry point to check for any extension being supported now, and all of the APIs use the same basic code for managing their extension/version querying).

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

You were correct, there was an extraneous call in there.

Thanks, and enjoy,

On Mon, Nov 4, 2013 at 8:46 PM, Mike C. Fletcher <mcfletch@vrplumber.com> 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:


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 C. Fletcher
  Designer, VR Plumber, Coder