[PyOpenGL-Devel] [ pyopengl-Bugs-1827190 ] Default (Numpy) array return values not accepted

[SourceForge.net <no...@so...>]

Bugs item #1827190, was opened at 2007-11-06 22:35
Message generated for change (Comment added) made by astraw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Waters (crwaters)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Default (Numpy) array return values not accepted

Initial Comment:
The values returned by the default array type, numpy, are not accepted by OpenGL; more importantly, they are not accepted by the respective set/bind functions.

This output is from the attached test file, run with the latest CVS revision:

glGenTextures(1) -> 1 (<type 'long'>)
glGenTextures(2) -> [2 3] (list: <type 'numpy.ndarray'>, elements: <type 'numpy.uint32'>)
Calling: glBindTexture(GL_TEXTURE_2D, 1)
         (created from glGenTextures(1))
    No Exceptions
Calling: glBindTexture(GL_TEXTURE_2D, 2)
         (created from glGenTextures(2), element 0)
    Exception Caught: argument 2: <type 'exceptions.TypeError'>: wrong type

The returned type of the array is numpy.ndarray, with each element having the type numpy.uint32. This element type is also not immediately convertable to a function argument type such as GLuint.

The return type of glGenTextures(1), however, is of the type long due to the special-case functionality. This is not the case for functions that do not handle special cases similar to this, such as OpenGL.GL.EXT.framebuffer_object.glGenFramebuffersEXT

A quick global work-around is to change the array type to ctypes after importing OpenGL:
 from OpenGL.arrays import formathandler
 formathandler.FormatHandler.chooseOutput( 'ctypesarrays' )

----------------------------------------------------------------------

Comment By: Andrew Straw (astraw)
Date: 2008-01-07 21:54

Message:
Logged In: YES 
user_id=210276
Originator: NO

I forwarded this bug report to the numpy-discussion list, where a bugfix
was implemented and workaround was discussed:

http://projects.scipy.org/pipermail/numpy-discussion/2008-January/030670.html

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 18:32

Message:
Logged In: YES 
user_id=34901
Originator: NO

I've added an optional flag to the top-level module which allows for using
numpy scalars. ALLOW_NUMPY_SCALARS which when true allows your test case to
succeed.

Coded in Python, however, it's rather slow (and rather poorly
implemented).  I looked into implementing this using the
__array_interface__ on scalars, but the data-pointer there appears to be
randomly generated.  Without that, a conversion at the Python level and
then passing onto the original function seems the only solution.

I doubt we'll get a *good* solution to this in the near term.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988