[PyOpenGL-Devel] [ pyopengl-Bugs-1827190 ] Default (Numpy) array return values not accepted
Brought to you by:
mcfletch
From: SourceForge.net <no...@so...> - 2009-07-19 02:42:38
|
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 |