Re: [PyOpenGL-Devel] pyopengl extension detection.

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

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:

  * I made the API-specific version/extension querying use a plug-in
    mechanism, with each API expected to provide the code in its own
    namespace (_types.py)
  * Currently this is *not* properly context/display/screen/HDC
    specific, but the idea is that each sub-class should be able to
    specify how to scope the caching
  * I added the concept of an assumed version for each plugin, so e.g.
    we assume at least glX [1,1] and gl [1,1]
  * I tried to provide a fallback for glXGetCurrentDisplay() (basically
    using raw X11)
  * I added an EGL version
  * I started on a WGL version of the plugin, but I haven't actually
    booted into Windows to work on it

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

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


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