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

Bugs item #1827190, was opened at 2007-11-06 17:35
Message generated for change (Comment added) made by mcfletch
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: Closed
>Resolution: Fixed
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: Mike C. Fletcher (mcfletch)
Date: 2009-07-18 22:42

Message:
Since 2.5.2 and 2.6 are fixed, I'm going to call this closed.

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

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-24 19:59

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

Right, I saw this in Python 2.5.2 changelog:

- The ctypes int types did not accept objects implementing
  __int__() in the constructor.

Nice to see this bug squashed then (it was really annoying to debug
because numpy array/integers look like python basic types in repr!).

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-02-24 18:46

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

AFAIK the default was *never* ctypes arrays.  ctypes arrays aren't
generally compatible with Numpy/Numeric-assuming code, so they are far more
likely to cause coding problems than Numpy scalars.  Thomas has fixed the
bug in ctypes (which wasn't calling __int__ on the values), so with the
next point release of Python we should see the problem fix itself.

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

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-24 18:12

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

Thus, can't we switch the default back to ctypesarrays until this is
resolved (if ever)?

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 19:50

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

Seems "pending" is considered "closed" for some reason.  Reopening so it's
not lost.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 19:49

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

Hmm, maybe I'm just having a bad ctypes day, but I don't see how to take
the buffer object (the proposed work-around) and convert its contents to a
ctypes.c_* type.  The buffer must have knowledge of its internal address,
but I don't see a member that gives me access to it.

Even if it did work, we'd be in the same boat with an extra Python
function call introduced as overhead for every single simple data-type
parameter.  This needs to happen down in the C code in ctypes to have any
hope of being fast enough IMO.

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

Comment By: Andrew Straw (astraw)
Date: 2008-01-07 16: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 13: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

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net