#174 Default (Numpy) array return values not accepted

v3.0.0
closed-fixed
GL (74)
5
2009-07-19
2007-11-06
No

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' )

Discussion

  • Chris Waters

    Chris Waters - 2007-11-06
     
  • Mike C. Fletcher

    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.

     
  • Mike C. Fletcher

    • labels: --> GL
    • assigned_to: nobody --> mcfletch
    • status: open --> pending
     
  • Mike C. Fletcher

    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.

     
  • Mike C. Fletcher

    • status: pending --> open
     
  • Mike C. Fletcher

    Logged In: YES
    user_id=34901
    Originator: NO

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

     
  • Giovanni Bajo

    Giovanni Bajo - 2008-02-24

    Logged In: YES
    user_id=727687
    Originator: NO

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

     
  • Mike C. Fletcher

    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.

     
  • Giovanni Bajo

    Giovanni Bajo - 2008-02-25

    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!).

     
  • Mike C. Fletcher

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

     
  • Mike C. Fletcher

    • status: open --> closed-fixed
     

Log in to post a comment.