[PyOpenGL-Devel] Need more comments from scientific community on python-dev

Mike C. Fletcher mcfletch at vrplumber.com
Sat Nov 4 10:21:12 CST 2006

Josh Marshall wrote:
> On 11/31/06, Fernando Perez <fperez.net at gmail.com> wrote:
>> Fernando Perez wrote:
>> ps - one more thing.  This guy:
>> http://blog.vrplumber.com/
>> 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.


  Mike C. Fletcher
  Designer, VR Plumber, Coder

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

More information about the Numpy-discussion mailing list