Re: Need more comments from scientific community on python-dev
On 11/31/06, Fernando Perez <fperez.net@gmail.com> wrote:
Fernando Perez wrote: ps - one more thing. This guy:
has been rewriting the OpenGL bindings using ctypes, and I've seen posts from him about numpy (in his blog). He might be able to contribute something...
I've been working on the OSX port and extensions for OpenGL-ctypes. (now released as PyOpenGL-3.00a, please test!). What Mike has done is define setuptools plugins to interface to different kinds of array data. The default type is ctypes arrays, or numpy arrays if numpy is installed. The data types handled are ctypes sized arrays, ctypes pointers, strings (read-only), and Python lists. (and old Numeric/ numarray via a non-default build.) Summaries of development and usage, resp, are found: http://pyopengl.sourceforge.net/ctypes/development.html http://pyopengl.sourceforge.net/ctypes/using.html Notes on array handling from the above:
Perhaps the most complex mechanisms in OpenGL-ctypes are those which implement the array-based operations which allow for using low-level blocks of formatted data to communicate with the OpenGL implementation. OpenGL-ctypes preferred basic array implementation is the (new) numpy reimplementation of the original Numeric Python.
The array handling functionality provided within OpenGL-ctypes is localised to the OpenGL.arrays sub-package. Within the package, there are two major classes, one (the FormatHandler) which implements an interface to a way of storing data in Python, and another (the ArrayDatatype) which models an OpenGL array format. The ArrayDatatype classes use FormatHandlers to manipulate array- compatible objects for use in the system. and on FormatHandlers, for each of the datatypes I mentioned earlier:
Each format handler is responsible for implementing an API that ArrayDatatypes can use to work with the Python data-format. Data- formats can support a subset of the API, they only need to support those aspects of the data-format which make sense. Now, I haven't spent much time looking at these parts of OpenGL- ctypes, as they have just worked for me. I would think that it would be trivial to write a FormatHandler which uses the ndarray interface and data type description to use any object implenting it as an input for OpenGL. This would include things such as PIL images.
Mike, can you give us your opinion on how a standardised data type descriptor would be helpful for PyOpenGL? The PEP and some information about it can be found here: http://www.scipy.org/ArrayInterfacePEP Cheers, Josh ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Josh Marshall wrote:
On 11/31/06, Fernando Perez <fperez.net@gmail.com> wrote:
Fernando Perez wrote: ps - one more thing. This guy:
has been rewriting the OpenGL bindings using ctypes, and I've seen posts from him about numpy (in his blog). He might be able to contribute something...
... Now, I haven't spent much time looking at these parts of OpenGL- ctypes, as they have just worked for me. I would think that it would be trivial to write a FormatHandler which uses the ndarray interface and data type description to use any object implenting it as an input for OpenGL. This would include things such as PIL images.
Yes, this is the purpose of the design, to allow users to write new format handlers that can be registered at run-time and act as first-class data-formats within the system. PIL images, custom vector objects, memory-mapped files, media buffers and the like are all contemplated as useful array storage formats.
Mike, can you give us your opinion on how a standardised data type descriptor would be helpful for PyOpenGL? The PEP and some information about it can be found here: http://www.scipy.org/ArrayInterfacePEP
A standardised data-type descriptor would be of some benefit for us, as it would allow a single handler to deal with larger numbers of storage formats (reducing the amount of coding required). That said, the spec as proposed has far more features than *most* OpenGL users will use (OpenGL being largely (though not exclusively) focused on simple, homogeneous data-types), and the handler mechanism largely abstracts away the problem for *us* at the moment. We wouldn't be able to get rid of the abstraction mechanism entirely, as we would still have data-types such as lists-of-lists-of-integers that wouldn't support the protocol. The likely efficiency of accessing the metadata (versus current implementation where in some cases we wind up producing a whole dictionary object with meta-data just to pull out a single value) would be attractive. We also need functionality to get at the data-pointer for the objects to make any description useful, though I suppose that's out of scope for this particular PEP. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
On 11/4/06, Mike C. Fletcher <mcfletch@vrplumber.com> wrote:
We wouldn't be able to get rid of the abstraction mechanism entirely, as we would still have data-types such as lists-of-lists-of-integers that wouldn't support the protocol.
Perhaps this will sound stupid, but I was thinking about extending some builtin Python types to provide datatype info. A list/tuple is an array of Python objects, an int/float/complex could return a datatype upon query. This could be very efficient if some predefined datatypes were already defined in the C-side. MPI provides predefined datatypes (MPI_INT, MPI_FLOAT) and new user-defined datatypes are created from them. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
participants (3)
-
Josh Marshall -
Lisandro Dalcin -
Mike C. Fletcher