pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] setting OpenGL.ERROR_CHECKING to False has strange consequence on function loading

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

On 02/18/2014 03:44 PM, rndblnch wrote:
> hello again,
>
> while moving some code to core profile, i found a strange interaction
> between the OpenGL.ERROR_CHECKING flag and the function loading mechanism.
> the following program (MacOSX specific for the glut core profile flag)
> prints True if error checking is enabled and prints False otherwise.
I haven't been able to duplicate it here (i.e. it always returns true on 
a Linux amd box).  My guess is that we are seeing an error from earlier 
in the process startup being interpreted as "function doesn't exist" 
when loading that function, but I can't see *how* that would occur, as 
the actual code to get the entry point shouldn't care about OpenGL errors.

Sorry to not be much help here,
Mike


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

Re: [PyOpenGL-Users] shader error handling rely on glGetObjectParameterivARB which is not in core profile

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

On 02/18/2014 04:46 PM, rndblnch wrote:
> hello again, last report for tonight...
>
> i am still testing core profile, and yet another corner case:
> OpenGL.GL.shaders.glCompileShader is imported from ARB.shader_objects
> extension and its error handling relies on glGetObjectParameterivARB ..
> which is not present in core profile.
> this leads to trouble when trying to report compilation errors:
This was due to being a bit lazy in wrapping the 2.0 version, I used 
precisely the same code as in the ARB extension, and in doing so made 
the core code depend on the ARB version of the functionality. bzr head 
*should* now fix this, though as the code actually worked on my machine 
I can't be sure the problem is actually fixed on true core-only 
profiles.  BTW, your script there works fine on GLSL 1.3, which is what 
Intel integrated graphics provides these days (at least on Linux).

Thanks,
Mike


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

[PyOpenGL-Users] shader error handling rely on glGetObjectParameterivARB which is not in core profile

[rndblnch <rnd...@gm...>]

hello again, last report for tonight...

i am still testing core profile, and yet another corner case:
OpenGL.GL.shaders.glCompileShader is imported from ARB.shader_objects
extension and its error handling relies on glGetObjectParameterivARB ..
which is not present in core profile.
this leads to trouble when trying to report compilation errors:

   % python3 10-gl3.2core.py 
   Traceback (most recent call last):

   [...]
   
     File "10-gl3.2core.py", line 37, in create_shader
       glCompileShader(shader)
     File
"OpenGL/platform/baseplatform.py",
line 32, in __call__
       return self.func( *args, **named )
     File
"OpenGL/GL/VERSION/GL_2_0.py",
line 145, in GLSLCheckError
       description= glGetInfoLog( cArguments[0] )
     File "latebind.pyx", line 44, in
OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1189)
     File
"OpenGL/GL/ARB/shader_objects.py",
line 134, in glGetInfoLogARB
       length = int(glGetObjectParameterivARB(obj, GL_INFO_LOG_LENGTH_ARB))
     File "latebind.pyx", line 44, in
OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1189)
     File
"OpenGL/GL/ARB/shader_objects.py",
line 86, in glGetObjectParameterivARB
       shader, pname, status
     File
"OpenGL/platform/baseplatform.py",
line 390, in __call__
       self.__name__, self.__name__,
   OpenGL.error.NullFunctionError: Attempt to call an undefined function
glGetObjectParameterivARB, check for bool(glGetObjectParameterivARB) before
calling


i guess it should be replaced by
OpenGL.GL.shaders.glGetProgramiv/glGetShaderiv but i don't see how to do
that without creating a circular dependency...
i stop bothering you for today,

renaud

Re: [PyOpenGL-Users] url to opengl-programmable in "sample code references" is wrong

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

On 14-02-18 08:03 AM, rndblnch wrote:
...
> the problem is here i guess (since the template for bitbucket already
> contains the /src/ part):
>
> http://bazaar.launchpad.net/~mcfletch/pyopengl/directdocs/view/head:/references.py#L240

Thanks, updated and tested via a click-through on the docs.

Enjoy,
Mike

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

[PyOpenGL-Users] setting OpenGL.ERROR_CHECKING to False has strange consequence on function loading

[rndblnch <rnd...@gm...>]

hello again,

while moving some code to core profile, i found a strange interaction
between the OpenGL.ERROR_CHECKING flag and the function loading mechanism.
the following program (MacOSX specific for the glut core profile flag)
prints True if error checking is enabled and prints False otherwise.

   import OpenGL
   #OpenGL.ERROR_CHECKING = False

   from OpenGL.GLUT import *

   def reshape(width, height): pass
   def display(): glutSwapBuffers()

   glutInit([])
   glutInitDisplayMode(GLUT_RGBA|GLUT_3_2_CORE_PROFILE)
   glutCreateWindow(b"test")
   glutReshapeFunc(reshape)
   glutDisplayFunc(display)

   from OpenGL.GL import glGenVertexArrays
   print bool(glGenVertexArrays)

i am currently investigating the difference in the code paths taken, but i
must admit that i am a bit confused...

renaud

Re: [PyOpenGL-Users] OpenGL.CONTEXT_CHECKING default value is not False as documented

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

On 14-02-18 07:47 AM, rndblnch wrote:
> hello,
>
> while profiling some of my code, i discovered that context checking is
> enabled by default, despite the documentation advertising the opposite (see
> OpenGL/__init__.py lines 79 vs. 185).
>
> i have no opinion on its default value (True is consistent with the other
> XXX_CHECKING flags) but maybe you should fix the docstring, and perhaps add
> a note about this flag in
> http://pyopengl.sourceforge.net/documentation/opengl_diffs.html since
> context checking introduces a rather high overhead.
The default value should still be no-checking. I set it to True while I 
was working on the refactoring of the raw hierarchy to catch errors and 
then forgot to return it.

Thanks,
Mike

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

[PyOpenGL-Users] url to opengl-programmable in "sample code references" is wrong

[rndblnch <rnd...@gm...>]

hello again,

while looking at the documentation of pyopengl, i saw that you have included
links to my opengl-programmable sample series in the doc.
but the links are wrong:
https://bitbucket.org/rndblnch/opengl-programmable/src/src/tip/xx-xx
instead of
https://bitbucket.org/rndblnch/opengl-programmable/src/tip/xx-xx
(with a single src)

the problem is here i guess (since the template for bitbucket already
contains the /src/ part):

http://bazaar.launchpad.net/~mcfletch/pyopengl/directdocs/view/head:/references.py#L240

renaud

[PyOpenGL-Users] OpenGL.CONTEXT_CHECKING default value is not False as documented

[rndblnch <rnd...@gm...>]

hello,

while profiling some of my code, i discovered that context checking is
enabled by default, despite the documentation advertising the opposite (see
OpenGL/__init__.py lines 79 vs. 185).

i have no opinion on its default value (True is consistent with the other
XXX_CHECKING flags) but maybe you should fix the docstring, and perhaps add
a note about this flag in
http://pyopengl.sourceforge.net/documentation/opengl_diffs.html since
context checking introduces a rather high overhead.

renaud

Re: [PyOpenGL-Users] PyOpenGL 3.1.0b1 released (finally)

[Nicolas R. <Nic...@in...>]

Thanks a lot for this release Mike. Really great update !
This will make our lives definitely easier (vispy project).

Nicolas


On 12 Feb 2014, at 17:51, Mike C. Fletcher <mcf...@vr...> wrote:

> PyOpenGL and PyOpenGL_accelerate 3.1.0b1 are now up on PyPI.  There's MS 
> Windows 32 and 64-bit installers for the windows-ians. The main 
> "features" planned for the 3.1.0 release (and available in the beta) are:
> 
>  * raw wrappers generated from the ARB source XML definitions, this
>    means that it covers a lot more extensions, including GLX, WGL, EGL
>    extensions (from prodding by Roman Valov)
>  * heavily restructured internally to make sub-packages less
>    inter-dependent (raw hierarchy is now somewhat self-contained)
>  * same code-base for Python 2.6, 2.7, 3.3 and 3.4, Python 2.5 is no
>    longer supported, 3.1 and 3.2 support isn't currently a priority
>  * accelerate modules regenerated with modern Cython
>  * Python 3.x and PyPy 2.x fixes (Tom Goddard, Renaud)
>  * dropping of ancient Numeric module as a supported array type (the
>    precursor to Numpy)
>  * experimental support for GLES, EGL
>  * experimental "buffer" protocol array support (not useful at the moment)
>  * array handler loading is now on-demand, so numpy is not loaded if
>    installed-but-not-used
>  * handle zero pointers in glReadPixels (Tim Sheerman-Chase)
>  * respect output-as-bytes flag in glGetTexImage* functions
>  * shader wrapper error messages are now longer to more commonly
>    include the actual description of the error in the displayed summary
> 
> This is a major update to the library (hence 3.1 instead of 3.0.3), and 
> there may be code breakage.  You are encouraged to update and test your 
> code with the betas before we land the 3.1 final.  You can download 
> Windows installers and source-code packages from:
> 
>  * https://pypi.python.org/pypi/PyOpenGL/3.1.0b1/
>  * https://pypi.python.org/pypi/PyOpenGL-accelerate/3.1.0b1
> 
> or install on Linux/OS-X with pip.
> 
> If there's anything (or anyone) I've forgotten in the release notes, or 
> bugs you encounter, feel free to post them here, email them to me 
> directly, or otherwise bat me over the head with them.
> 
> Enjoy,
> Mike
> 
> -- 
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
> 
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] PyOpenGL 3.1.0b1 released (finally)

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

PyOpenGL and PyOpenGL_accelerate 3.1.0b1 are now up on PyPI.  There's MS 
Windows 32 and 64-bit installers for the windows-ians. The main 
"features" planned for the 3.1.0 release (and available in the beta) are:

  * raw wrappers generated from the ARB source XML definitions, this
    means that it covers a lot more extensions, including GLX, WGL, EGL
    extensions (from prodding by Roman Valov)
  * heavily restructured internally to make sub-packages less
    inter-dependent (raw hierarchy is now somewhat self-contained)
  * same code-base for Python 2.6, 2.7, 3.3 and 3.4, Python 2.5 is no
    longer supported, 3.1 and 3.2 support isn't currently a priority
  * accelerate modules regenerated with modern Cython
  * Python 3.x and PyPy 2.x fixes (Tom Goddard, Renaud)
  * dropping of ancient Numeric module as a supported array type (the
    precursor to Numpy)
  * experimental support for GLES, EGL
  * experimental "buffer" protocol array support (not useful at the moment)
  * array handler loading is now on-demand, so numpy is not loaded if
    installed-but-not-used
  * handle zero pointers in glReadPixels (Tim Sheerman-Chase)
  * respect output-as-bytes flag in glGetTexImage* functions
  * shader wrapper error messages are now longer to more commonly
    include the actual description of the error in the displayed summary

This is a major update to the library (hence 3.1 instead of 3.0.3), and 
there may be code breakage.  You are encouraged to update and test your 
code with the betas before we land the 3.1 final.  You can download 
Windows installers and source-code packages from:

  * https://pypi.python.org/pypi/PyOpenGL/3.1.0b1/
  * https://pypi.python.org/pypi/PyOpenGL-accelerate/3.1.0b1

or install on Linux/OS-X with pip.

If there's anything (or anyone) I've forgotten in the release notes, or 
bugs you encounter, feel free to post them here, email them to me 
directly, or otherwise bat me over the head with them.

Enjoy,
Mike

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

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> 
> On 14-01-31 05:03 AM, rndblnch wrote:
> > Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:
> ...
> > great, thanks!
> >
> > on my side, everything is ok on MacOSX 10.9.1, python2.7 & python3.3.
> >
> > the only regression i found now is when using pypy-2.1 or pypy3-2.1, but
> > they are related to pypy's implementation of ctypes, and i am not sure that
> > the pypy devs have any interest in fixing it as they are strongly supporting
> > cffi now.
> > i will report my finding to them anyway.
> > by the way, pypy has never sped any of my opengl code...
> 
> Yeah, I'm seeing extremely poor performance under PyPy on what few demos 
> I can get running without Pygame and Numpy.  I fixed the GLUT error you 
> pointed out, and registered some data-types that have different names in 
> PyPy vs. CPython, and at least the core tests and a few GLUT Demos now 
> run under PyPy.
> 
> I'd say we're about ready for a 3.1.0b1 release for wider testing, so 
> I'll do that the next time I get a few hours to work on PyOpenGL.

great!
it works for me at r664 except when i pass tuples or lists instead of bytes
to functions expecting a pointer to  data under pypy (in my case, the last
argument of glUniformMatrix3fv).
the following patch fixes this (i guess that pypy does not throw the exact
same exceptions than cpython):

    === modified file 'OpenGL/arrays/lists.py'
    --- OpenGL/arrays/lists.py	2014-01-02 20:27:57 +0000
    +++ OpenGL/arrays/lists.py	2014-02-10 20:42:23 +0000
    @@ -47,7 +47,7 @@
         def from_param( self, instance, typeCode=None ):
             try:
                 return ctypes.byref( instance )
    -        except TypeError as err:
    +        except (TypeError, AttributeError) as err:
                 array = self.asArray( instance, typeCode )
                 pp = ctypes.c_void_p( ctypes.addressof( array ) )
                 pp._temporary_array_ = (array,)


and here the call stack i was getting before applying this patch:

  File
"site-packages/PyOpenGL-3.1.0a4-py3.2.egg/OpenGL/platform/baseplatform.py",
line 32, in __call__
    return self.func( *args, **named )
  File
"lib_pypy/_ctypes/function.py", line
339, in __call__
    args, kwargs)
  File
"lib_pypy/_ctypes/function.py", line
561, in _convert_args
    keepalive, newarg, newargtype = self._conv_param(argtype, args[i])
  File
"/lib_pypy/_ctypes/function.py", line
455, in _conv_param
    arg = argtype.from_param(arg)
  File
"/site-packages/PyOpenGL-3.1.0a4-py3.2.egg/OpenGL/arrays/arraydatatype.py",
line 123, in from_param
    return cls.getHandler(value).from_param( value, cls.typeConstant )
  File
"/site-packages/PyOpenGL-3.1.0a4-py3.2.egg/OpenGL/arrays/lists.py",
line 49, in from_param
    return ctypes.byref( instance )
  File "/lib_pypy/_ctypes/basics.py",
line 174, in byref
    return pointer(cdata)
  File "/lib_pypy/_ctypes/pointer.py", line
184, in pointer
    return POINTER(type(inst))(inst)
  File
"/lib_pypy/_ctypes/pointer.py", line
178, in POINTER
    {'_type_': cls})
  File
"/lib_pypy/_ctypes/pointer.py", line
34, in __new__
    self.set_type(obj, typedict['_type_'])
  File
"/lib_pypy/_ctypes/pointer.py", line
73, in set_type
    self._ffiargtype = _ffi.types.Pointer(TP.get_ffi_argtype())
AttributeError: type object 'list' has no attribute 'get_ffi_argtype'

renaud

> 
> Have fun,
> Mike
> 

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

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

On 14-01-31 05:03 AM, rndblnch wrote:
> Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:
...
> great, thanks!
>
> on my side, everything is ok on MacOSX 10.9.1, python2.7 & python3.3.
>
> the only regression i found now is when using pypy-2.1 or pypy3-2.1, but
> they are related to pypy's implementation of ctypes, and i am not sure that
> the pypy devs have any interest in fixing it as they are strongly supporting
> cffi now.
> i will report my finding to them anyway.
> by the way, pypy has never sped any of my opengl code...

Yeah, I'm seeing extremely poor performance under PyPy on what few demos 
I can get running without Pygame and Numpy.  I fixed the GLUT error you 
pointed out, and registered some data-types that have different names in 
PyPy vs. CPython, and at least the core tests and a few GLUT Demos now 
run under PyPy.

I'd say we're about ready for a 3.1.0b1 release for wider testing, so 
I'll do that the next time I get a few hours to work on PyOpenGL.

Have fun,
Mike

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

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> I've eliminated a couple of other name-pollution issues, but there's 
> still a dozen or so "shouldn't be there" names in the final import 
> namespace for GL.  Unfortunately, using __all__ rather bloats the 
> modules (there's a *lot* of names in the namespaces). So I've been doing 
> that cleanup one-by-one with renames to _ prefixed names.
> 
> I'll need to re-run the Linux tests, as those changes have modified 
> *hundreds* of files, and then I still need to get the basic Win32 tests 
> done to do the beta 1 release.

great, thanks!

on my side, everything is ok on MacOSX 10.9.1, python2.7 & python3.3.

the only regression i found now is when using pypy-2.1 or pypy3-2.1, but
they are related to pypy's implementation of ctypes, and i am not sure that
the pypy devs have any interest in fixing it as they are strongly supporting
cffi now.
i will report my finding to them anyway.
by the way, pypy has never sped any of my opengl code...

one example is the ctypes.c_char_p wrapper used in raw.GLUT:

    Python 2.7.3 (480845e6b1dd, Jul 31 2013, 10:58:28)
    [PyPy 2.1.0 with GCC 4.2.1 Compatible Clang Compiler] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``random bugs in random (not a
    funny joke)''
    >>>> from ctypes import c_char_p
    >>>> class STRING( c_char_p ):
    ....     @classmethod
    ....     def from_param( cls, value ):
    ....         if isinstance( value, unicode ):
    ....             value = value.encode( 'utf-8' )
    ....         return super( STRING, cls ).from_param( value )
    .... 
    >>>> STRING.from_param("titi")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 6, in from_param
    AttributeError: 'super' object has no attribute 'from_param'

> 
> Thanks,
> Mike
> 

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

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

On 14-01-29 09:16 AM, rndblnch wrote:
...
>
> i have done some testing with python3 too, and got a couple of syntax errors
> because the keyword "in" is used as argument name by two functions.
> the patch below shows where it happens (the fix should probably done at the
> generator level though):
I've fixed that, and run all of the parameter names through a test to 
filter out *any* python keyword (on the python (2.7) on which the 
generator is run).  Note that I went with the suffixed rather than 
prefixed for (in_ rather than _in) for the names.  Those were the only 
cases found with that check, btw.

> and a quick remark: a Logger instance named log is imported into the global
> namespace, so it shadows the math function when doing something like that:
> """
> from math import log
> from OpenGL.GLUT import *
> """
> perhaps it could be possible to exclude it from * import (by setting a
> __all__, or using _log as its name)?
> not very important, i know...
I've eliminated a couple of other name-pollution issues, but there's 
still a dozen or so "shouldn't be there" names in the final import 
namespace for GL.  Unfortunately, using __all__ rather bloats the 
modules (there's a *lot* of names in the namespaces). So I've been doing 
that cleanup one-by-one with renames to _ prefixed names.

I'll need to re-run the Linux tests, as those changes have modified 
*hundreds* of files, and then I still need to get the basic Win32 tests 
done to do the beta 1 release.

Thanks,
Mike

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

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> I looked into it, and there was, indeed, a problem with the ctypes 
> pointer handling.  Basically we were getting pointer-to-pointer (i.e. 
> the address of the pointer variable) instead of the pointer's value when 
> doing a dataPointer() call on them.  I've fixed that on bzr head, and 
> all of your samples now seem to run correctly on bzr head. What's weird 
> is that code hadn't changed; it seems that something higher-level meant 
> that the code-path just wasn't being executed in the old PyOpenGL releases.

ok, indeed, it works for me at rev 656, thanks.

> By the way, do you have a tutorial (text) somewhere connected with your 
> samples?

no, unfortunately not.
this is support material for an opengl class, but the documents are in french :(

> And would you like the code linked into the PyOpenGL 
> documentation samples (i.e. when someone looks at the glXxxxPointer 
> functions they'd see a reference to your hg repository?)

sure, i would be honored :)
two quick notes:
- there are two branches, python2 is python2.5+ compatible, and default is
python2.6+ and python3+ compatible with a single code base
- demo 10-gl3.2core.py is MacOSX specific as it uses the
GLUT_3_2_CORE_PROFILE capability.
i guess that freeglut also offers the possibility to open a 3.2 core
compatible context, i will look into this to provide a platform independent
version of this code.

> I fixed an (unrelated) bug that was preventing the various configuration 
> flags (e.g. FULL_LOGGING) from running, and regenerated the 
> OpenGL_accelerate wrappers with the new Cython release.
> 
> I *think* we're fairly close to a beta-1 release for PyOpenGL 3.1 at 
> this point.  I still need to get some time to run the Windows tests and 
> re-run the Linux tests with the updated Cython wrappers.

i have done some testing with python3 too, and got a couple of syntax errors
because the keyword "in" is used as argument name by two functions.
the patch below shows where it happens (the fix should probably done at the
generator level though):

=== modified file 'OpenGL/raw/GL/EXT/vertex_shader.py'
--- OpenGL/raw/GL/EXT/vertex_shader.py	2013-11-22 15:15:02 +0000
+++ OpenGL/raw/GL/EXT/vertex_shader.py	2014-01-29 10:48:57 +0000
@@ -217,7 +217,7 @@
 def glShaderOp3EXT(op,res,arg1,arg2,arg3):pass
 @_f
 @_p.types(None,_cs.GLuint,_cs.GLuint,_cs.GLenum,_cs.GLenum,_cs.GLenum,_cs.GLenum)
-def glSwizzleEXT(res,in,outX,outY,outZ,outW):pass
+def glSwizzleEXT(res,_in,outX,outY,outZ,outW):pass
 @_f
 @_p.types(None,_cs.GLuint,_cs.GLenum,_cs.GLuint,ctypes.c_void_p)
 def glVariantPointerEXT(id,type,stride,addr):pass
@@ -248,4 +248,4 @@
 def glVariantusvEXT(id,addr):pass
 @_f
 @_p.types(None,_cs.GLuint,_cs.GLuint,_cs.GLenum,_cs.GLenum,_cs.GLenum,_cs.GLenum)
-def glWriteMaskEXT(res,in,outX,outY,outZ,outW):pass
+def glWriteMaskEXT(res,_in,outX,outY,outZ,outW):pass


and a quick remark: a Logger instance named log is imported into the global
namespace, so it shadows the math function when doing something like that:
"""
from math import log
from OpenGL.GLUT import *
"""
perhaps it could be possible to exclude it from * import (by setting a
__all__, or using _log as its name)?
not very important, i know...

thanks again,
i will be happy to do more testing once 3.1b1 is out (pypy and pypy3:)

renaud

> 
> Thanks,
> Mike
> 

[PyOpenGL-Users] Latest Version

[Kai W. <kai...@gm...>]

Hi all,

Could somebody point me to where I can find the latest versions for
testing? I have stumbled across some Python3 related bugs (e.g. `long` is
expected to be defined in glBufferSubData), and I wanted to test against
the latest version to make sure I don't report things already fixed.

Regards,
Kai Wohlfahrt

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

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

On 14-01-24 04:14 PM, rndblnch wrote:
> Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:
...
> it does not crash any more.
> however on my personal test suite (the same program converted step by step
> from using OpenGL 1. to modern OpenGL, see
> https://bitbucket.org/rndblnch/opengl-programmable/) it works until the
> introduction of vertex attributes (steps 01-direct.py to 06-perpixel.py
> work, but 07-attrib.py, 08-pbo.py, etc. give a black screen).
> i suspect that the pointer/offset parameter of the glXxxxPointer functions
> is not handled properly, i will look into it (i use ctypes arrays, no numpy).
I looked into it, and there was, indeed, a problem with the ctypes 
pointer handling.  Basically we were getting pointer-to-pointer (i.e. 
the address of the pointer variable) instead of the pointer's value when 
doing a dataPointer() call on them.  I've fixed that on bzr head, and 
all of your samples now seem to run correctly on bzr head. What's weird 
is that code hadn't changed; it seems that something higher-level meant 
that the code-path just wasn't being executed in the old PyOpenGL releases.

By the way, do you have a tutorial (text) somewhere connected with your 
samples? And would you like the code linked into the PyOpenGL 
documentation samples (i.e. when someone looks at the glXxxxPointer 
functions they'd see a reference to your hg repository?)

I fixed an (unrelated) bug that was preventing the various configuration 
flags (e.g. FULL_LOGGING) from running, and regenerated the 
OpenGL_accelerate wrappers with the new Cython release.

I *think* we're fairly close to a beta-1 release for PyOpenGL 3.1 at 
this point.  I still need to get some time to run the Windows tests and 
re-run the Linux tests with the updated Cython wrappers.

Thanks,
Mike

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

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> Indeed it did.  I tracked down the glGetString() calls, they happened 
> because the image-wrappers do a bool( function ) on various functions 
> which are GL_VERSION_1_2 *on import*, that is, they look at the 
> functions and say "do you exist" and then decide whether to wrap them 
> with convenience code.
> 
> If you can test out bzr head on your machine it should confirm the fix.  
> I'll start running through the Linux and Windows testing in the meantime 
> to see if there's any regressions caused by it.

it does not crash any more.
however on my personal test suite (the same program converted step by step
from using OpenGL 1. to modern OpenGL, see
https://bitbucket.org/rndblnch/opengl-programmable/) it works until the
introduction of vertex attributes (steps 01-direct.py to 06-perpixel.py
work, but 07-attrib.py, 08-pbo.py, etc. give a black screen).
i suspect that the pointer/offset parameter of the glXxxxPointer functions
is not handled properly, i will look into it (i use ctypes arrays, no numpy).

> Thanks,

you are more than welcome,
thank you for your work on PyOpenGL

renaud

> Mike

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

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

On 01/21/2014 06:47 AM, rndblnch wrote:
> hello,
>
> i finally managed to get some time to look at the early crash on Mac OS X
> that occurs on "from OpenGL import GL" since the xml-generation merge.
> it turns out that somehow, the import process triggers a call to glGetString.
> and if no opengl context is initialized at this point, it segfaults.
> however, if the import is done after a proper context is initialized, the
> import works and seams functional (no extensive testing though).
> the minimal program below works for me (notice the gl import after the
> glutCreateWindow).
>
> hope this helps,

Indeed it did.  I tracked down the glGetString() calls, they happened 
because the image-wrappers do a bool( function ) on various functions 
which are GL_VERSION_1_2 *on import*, that is, they look at the 
functions and say "do you exist" and then decide whether to wrap them 
with convenience code.

If you can test out bzr head on your machine it should confirm the fix.  
I'll start running through the Linux and Windows testing in the meantime 
to see if there's any regressions caused by it.

Thanks,
Mike

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

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> 
> On 01/21/2014 06:47 AM, rndblnch wrote:
> > hello,
> >
> > i finally managed to get some time to look at the early crash on Mac OS X
> > that occurs on "from OpenGL import GL" since the xml-generation merge.
> > it turns out that somehow, the import process triggers a call to
glGetString.
> > and if no opengl context is initialized at this point, it segfaults.
> > however, if the import is done after a proper context is initialized, the
> > import works and seams functional (no extensive testing though).
> > the minimal program below works for me (notice the gl import after the
> > glutCreateWindow).
> Thanks Renaud,
> 
> That gives me an idea how to track it down.  The issue will likely be in 
> the extension handling code, which was modified to support all of the 
> new extension types in GLE, EGL, WGL, etc.  Apparently I wound up moving 
> a call to glGetString before context init.

yes, that was my intuition too.
it is confirmed: if you comment out the 2 calls to glGetString in
OpenGL/extension.py, OpenGL.GL loads (but no extension is available).
however, i could not yet track the code path from import to the call to
glGetString.
i will try to look at it.

renaud

> 
> Appreciated,
> Mike
> 

Re: [PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

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

On 01/21/2014 06:47 AM, rndblnch wrote:
> hello,
>
> i finally managed to get some time to look at the early crash on Mac OS X
> that occurs on "from OpenGL import GL" since the xml-generation merge.
> it turns out that somehow, the import process triggers a call to glGetString.
> and if no opengl context is initialized at this point, it segfaults.
> however, if the import is done after a proper context is initialized, the
> import works and seams functional (no extensive testing though).
> the minimal program below works for me (notice the gl import after the
> glutCreateWindow).
Thanks Renaud,

That gives me an idea how to track it down.  The issue will likely be in 
the extension handling code, which was modified to support all of the 
new extension types in GLE, EGL, WGL, etc.  Apparently I wound up moving 
a call to glGetString before context init.

Appreciated,
Mike


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

[PyOpenGL-Users] crash on import on Mac OS X after xml-generation merge explained

[rndblnch <rnd...@gm...>]

hello,

i finally managed to get some time to look at the early crash on Mac OS X
that occurs on "from OpenGL import GL" since the xml-generation merge.
it turns out that somehow, the import process triggers a call to glGetString.
and if no opengl context is initialized at this point, it segfaults.
however, if the import is done after a proper context is initialized, the
import works and seams functional (no extensive testing though).
the minimal program below works for me (notice the gl import after the
glutCreateWindow).

hope this helps,

renaud

	from OpenGL.GLUT import *
	glutInit()
	glutCreateWindow("test")
	from OpenGL.GL import *
	def display():
		glClear(GL_COLOR_BUFFER_BIT)
		glutSwapBuffers()
	def reshape(w, h):
		glViewport(0, 0, w, h)
		glutPostRedisplay()
	glutDisplayFunc(display)
	glutReshapeFunc(reshape)
	glutMainLoop()

Re: [PyOpenGL-Users] glGenVertexArrays present with python/absent with python3

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

On 14-01-16 04:18 AM, rndblnch wrote:
> rndblnch <rndblnch <at> gmail.com> writes:
>
>> Hello,
>>
>> I am experimenting with OpenGL 3.2 core using PyOpenGL 3.0.2
>> I am experiencing something strange: a function (glGenVertexArrays) that is
>> present when I use python 2.7 is absent when I use python 3.3.
>> Maybe the automatic conversion from 2to3 breaks something?
> Hello again, found the pb: OpenGL.extensions.VERSION_EXTENSIONS contains
> extension names as strings, but they should be bytes on python3.
> the patch below corrects that:
Applied to bzr head.

Thanks,
Mike

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

[PyOpenGL-Users] Mac OS X GLUT support

[rndblnch <rnd...@gm...>]

hello,

GLUT on Mac OS X provides some non-standard extensions.
here is a patch to provide them to PyOpenGL users:

diff -ru PyOpenGL-3.0.2/OpenGL/GLUT/osx.py
PyOpenGL-3.0.2-mine/OpenGL/GLUT/osx.py
--- PyOpenGL-3.0.2/OpenGL/GLUT/osx.py	2014-01-16 15:57:45.000000000 +0100
+++ PyOpenGL-3.0.2-mine/OpenGL/GLUT/osx.py	2014-01-16 16:03:59.000000000 +0100
@@ -1,5 +1,10 @@
 """OSX specific extensions to GLUT"""
 from OpenGL import platform
+from OpenGL import constant
+from OpenGL.GLUT import special
+
+GLUT_NO_RECOVERY = constant.Constant( 'GLUT_NO_RECOVERY', 1024)
+GLUT_3_2_CORE_PROFILE = constant.Constant( 'GLUT_3_2_CORE_PROFILE', 2048)
 
 glutCheckLoop = platform.createBaseFunction( 
     'glutCheckLoop', dll=platform.GLUT, resultType=None, 
@@ -7,3 +12,7 @@
     doc='glutCheckLoop(  ) -> None', 
     argNames=(),
 )
+
+glutWMCloseFunc = special.GLUTCallback(
+    'WMClose', (), (),
+)

renaud

Re: [PyOpenGL-Users] glGenVertexArrays present with python/absent with python3

[rndblnch <rnd...@gm...>]

rndblnch <rndblnch <at> gmail.com> writes:

> 
> Hello,
> 
> I am experimenting with OpenGL 3.2 core using PyOpenGL 3.0.2
> I am experiencing something strange: a function (glGenVertexArrays) that is
> present when I use python 2.7 is absent when I use python 3.3.
> Maybe the automatic conversion from 2to3 breaks something?

Hello again, found the pb: OpenGL.extensions.VERSION_EXTENSIONS contains
extension names as strings, but they should be bytes on python3.
the patch below corrects that:


diff -ru PyOpenGL-3.0.2/OpenGL/extensions.py
PyOpenGL-3.0.2-mine/OpenGL/extensions.py
--- PyOpenGL-3.0.2/OpenGL/extensions.py	2012-09-15 06:28:20.000000000 +0200
+++ PyOpenGL-3.0.2-mine/OpenGL/extensions.py	2014-01-16 10:10:54.000000000 +0100
@@ -17,66 +17,66 @@
 # version tuple -> list of implicitly included extensions...
 VERSION_EXTENSIONS = [
     ((3,0), [
-        'GL_ARB_vertex_array_object',
-        'GL_ARB_texture_buffer_object',
-        'GL_ARB_framebuffer_object',
-        'GL_ARB_map_buffer_range',
+        as_8_bit('GL_ARB_vertex_array_object'),
+        as_8_bit('GL_ARB_texture_buffer_object'),
+        as_8_bit('GL_ARB_framebuffer_object'),
+        as_8_bit('GL_ARB_map_buffer_range'),
     ]),
     ((3,1), [
-        'GL_ARB_copy_buffer',
-        'GL_ARB_uniform_buffer_object',
+        as_8_bit('GL_ARB_copy_buffer'),
+        as_8_bit('GL_ARB_uniform_buffer_object'),
     ]),
     ((3,2), [
-        'GL_ARB_draw_elements_base_vertex',
-        'GL_ARB_provoking_vertex',
-        'GL_ARB_sync',
-        'GL_ARB_texture_multisample',
+        as_8_bit('GL_ARB_draw_elements_base_vertex'),
+        as_8_bit('GL_ARB_provoking_vertex'),
+        as_8_bit('GL_ARB_sync'),
+        as_8_bit('GL_ARB_texture_multisample'),
     ]),
     ((3,3), [
-        'GL_ARB_texture_multisample',
-        'GL_ARB_blend_func_extended',
-        'GL_ARB_sampler_objects',
-        'GL_ARB_explicit_attrib_location',
-        'GL_ARB_occlusion_query2',
-        'GL_ARB_shader_bit_encoding',
-        'GL_ARB_texture_rgb10_a2ui',
-        'GL_ARB_texture_swizzle',
-        'GL_ARB_timer_query',
-        'GL_ARB_vertex_type_2_10_10_10_rev',
+        as_8_bit('GL_ARB_texture_multisample'),
+        as_8_bit('GL_ARB_blend_func_extended'),
+        as_8_bit('GL_ARB_sampler_objects'),
+        as_8_bit('GL_ARB_explicit_attrib_location'),
+        as_8_bit('GL_ARB_occlusion_query2'),
+        as_8_bit('GL_ARB_shader_bit_encoding'),
+        as_8_bit('GL_ARB_texture_rgb10_a2ui'),
+        as_8_bit('GL_ARB_texture_swizzle'),
+        as_8_bit('GL_ARB_timer_query'),
+        as_8_bit('GL_ARB_vertex_type_2_10_10_10_rev'),
     ]),
     ((4,0), [
-        'GL_ARB_texture_query_lod',
-        'GL_ARB_draw_indirect',
-        'GL_ARB_gpu_shader5',
-        'GL_ARB_gpu_shader_fp64',
-        'GL_ARB_shader_subroutine',
-        'GL_ARB_tessellation_shader',
-        'GL_ARB_texture_buffer_object_rgb32',
-        'GL_ARB_texture_cube_map_array',
-        'GL_ARB_texture_gather',
-        'GL_ARB_transform_feedback2',
-        'GL_ARB_transform_feedback3',
+        as_8_bit('GL_ARB_texture_query_lod'),
+        as_8_bit('GL_ARB_draw_indirect'),
+        as_8_bit('GL_ARB_gpu_shader5'),
+        as_8_bit('GL_ARB_gpu_shader_fp64'),
+        as_8_bit('GL_ARB_shader_subroutine'),
+        as_8_bit('GL_ARB_tessellation_shader'),
+        as_8_bit('GL_ARB_texture_buffer_object_rgb32'),
+        as_8_bit('GL_ARB_texture_cube_map_array'),
+        as_8_bit('GL_ARB_texture_gather'),
+        as_8_bit('GL_ARB_transform_feedback2'),
+        as_8_bit('GL_ARB_transform_feedback3'),
     ]),
     ((4,1), [
-        'GL_ARB_ES2_compatibility',
-        'GL_ARB_get_program_binary',
-        'GL_ARB_separate_shader_objects',
-        'GL_ARB_shader_precision',
-        'GL_ARB_vertex_attrib_64bit',
-        'GL_ARB_viewport_array',
+        as_8_bit('GL_ARB_ES2_compatibility'),
+        as_8_bit('GL_ARB_get_program_binary'),
+        as_8_bit('GL_ARB_separate_shader_objects'),
+        as_8_bit('GL_ARB_shader_precision'),
+        as_8_bit('GL_ARB_vertex_attrib_64bit'),
+        as_8_bit('GL_ARB_viewport_array'),
     ]),
     ((4,2), [
-        'GL_ARB_base_instance',
-        'GL_ARB_shading_language_420pack',
-        'GL_ARB_transform_feedback_instanced',
-        'GL_ARB_compressed_texture_pixel_storage',
-        'GL_ARB_conservative_depth',
-        'GL_ARB_internalformat_query',
-        'GL_ARB_map_buffer_alignment',
-        'GL_ARB_shader_atomic_counters',
-        'GL_ARB_shader_image_load_store',
-        'GL_ARB_shading_language_packing',
-        'GL_ARB_texture_storage',
+        as_8_bit('GL_ARB_base_instance'),
+        as_8_bit('GL_ARB_shading_language_420pack'),
+        as_8_bit('GL_ARB_transform_feedback_instanced'),
+        as_8_bit('GL_ARB_compressed_texture_pixel_storage'),
+        as_8_bit('GL_ARB_conservative_depth'),
+        as_8_bit('GL_ARB_internalformat_query'),
+        as_8_bit('GL_ARB_map_buffer_alignment'),
+        as_8_bit('GL_ARB_shader_atomic_counters'),
+        as_8_bit('GL_ARB_shader_image_load_store'),
+        as_8_bit('GL_ARB_shading_language_packing'),
+        as_8_bit('GL_ARB_texture_storage'),
     ]),
 ]