Re: [Numpy-discussion] [PyOpenGL-Devel] Need more comments from scientific community on python-dev

[Mike C. F. <mcf...@vr...>]

Josh Marshall wrote:
> On 11/31/06, Fernando Perez <fpe...@gm...> 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.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com