Re: [PyOpenGL-Users] using glGetSynciv

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

On 11-05-24 05:33 AM, Henry Gomersall wrote:
> On Mon, 2011-05-23 at 22:55 -0400, Mike C. Fletcher wrote:
>> Okay, I constructed my own test case so I could see what the problem
>> is.  There was a bug in the declaration of GLsync, which was declared
>> to
>> be a c_void_p, it should have been declared as a ctypes.POINTER(
>> structure ).  I had thought c_void_p would create an opaque pointer
>> type
>> as a return-type, but apparently ctypes short-circuits it to return an
>> integer.
>>
>> I've checked a fix into bzr, and that should appear in the next
>> release
>> of PyOpenGL.  In the meantime, you can patch your copy of PyOpenGL
>> with
>> this: 
> Yeah, that fixes it - thank you. I've got the fence test code working as
> follows now:
>
> from OpenGL.GL.ARB import sync as GL_sync
> ...
> my_sync = \
> 	GL_sync.glFenceSync(GL_sync.GL_SYNC_GPU_COMMANDS_COMPLETE, 0)
>         
> fence_status = GL.GLint(0)
> GL_sync.glGetSynciv(my_sync,
> GL_sync.GL_SYNC_STATUS, GL.GLint(1), GL.GLint(0), fence_status)
>         
> print GL_sync.GL_UNSIGNALED == fence_status.value
>
> A couple of things come to light with this code. Firstly, as it is
> fence_status can only return a single argument. I couldn't work out how
> to instantiate GLintArray (it allows raises the following exception:
> TypeError: Cannot create instance: has no _type_ ). This isn't a problem
> as it stands because all the parameters will only return a single value.
>>> from OpenGL.arrays import GLintArray
>>> GLintArray.zeros( (2,3) )
array([[0, 0, 0],
       [0, 0, 0]], dtype=int32)
> Secondly, its pretty unpythonic as it stands. I understand that the
> PyOpenGL is a pretty thin shim around OpenGL, but this seems like a good
> opportunity for a little more logic on the python side, returning a
> datatype that is more conducive to being tested, or even better, a whole
> wrapper around the sync object.
>
> Is there any movement by anyone to make the whole OpenGL experience more
> pythonic? It strikes me that its starting to make a lot of sense with
> the buffers and shaders paradigm. I guess there is something towards
> this end with Qt and PySide/PyQt. Do any of the various game engines
> offer similar?
I'm torn on the issue.  Historically every time we (or I) have pulled
higher-level wrapper functionality into the core package, we have wound
up regretting it as the march of years means the APIs become obsolete or
broken (or just need to be maintained).  That said, I've recently added
the VBO and GL.shaders wrappers, mostly because it was so painful
working with the low-level APIs that I couldn't get demos/tests written
without them.

The problem seems to be finding a balance between making it easy to
code, and getting so radically far from the underlying API that we've
created a new intermediate API.  A truly usable/pythonic 3D API should
likely be a separate package with PyOpenGL (or just raw OpenGL) as a
dependency (i.e. a rendering engine).  At least, that's how I feel about
it this morning, before I have my coffee :) .

The ARB.sync module does appear rather awkward right now, as it appears
the ARB is planning for lots more features than are currently
available.  It would likely be reasonable to provide a glGetsynciv
wrapper that creates the arrays for you if you pass None.  For
reference, here's what my test code looks like:

http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/arbsync.py
<http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/arbsync.py>

And here's the convenience wrapper I've just added:

http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/view/head:/OpenGL/GL/ARB/sync.py
<http://bazaar.launchpad.net/%7Emcfletch/pyopengl/trunk/view/head:/OpenGL/GL/ARB/sync.py>

It doesn't attempt to create a higher-level abstraction, just makes the
function easier to call from Python code by providing an alias that
auto-allocates the buffers for you.

Enjoy,
Mike

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