Re: [PyOpenGL-Users] Pointer functions copying memory.

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

Strangely, that first post of Guido's is what gave me the impression the 
buffer API was considered less than optimal for continued use.  That is, 
it seems to be considered broken, and there are a number of proposals to 
fix it, but the API as it stands is suboptimal and fragile (likely to 
cause memory access failures).  The buffer object is just more broken :) .

As you (Thomas) are certainly more involved in C-level Python 
programming, I will defer to your understanding.

I'm still not sure that the buffer API can be used for the OpenGL array 
functions.  OpenGL takes a contiguous memory array, which it copies to 
the OpenGL engine.  As far as I can see, there is no support for objects 
which override iteration to point to methods/functions.  If we are 
simply using the buffer API to copy into a contiguous memory array... 
well... the Numeric Python version is already doing that, and causing 
the slowdown.

Of course, I may simply be misunderstanding something, happens all the time,
Mike

Thomas Wouters wrote:

>On Mon, Feb 03, 2003 at 12:39:26PM -0500, Mike C. Fletcher wrote:
>  
>
>>The biggest problem I see is that the buffer API is loosely considered 
>>deprecated.
>>    
>>
>
>I don't believe this is the case. Buffer *objects* (which the 'buffer'
>builtin function / constructor returns) are somewhat-slilently deprecated,
>but I don't believe the actual buffer API is. I haven't been paying
>attention to python-dev lately, but all discussions I recall were about
>buffer objects, not the API, and I have seen no-one complain about the API
>itself (at least not all negatively :) For instance this posting by Guido:
>
>http://mail.python.org/pipermail/python-dev/2000-October/009974.html
>
>And this more recent discussion:
>
>http://mail.python.org/pipermail/python-dev/2002-June/026018.html
>
>>From the PEP (Python Enhancement Proposals) list, I see a proposal to
>more-or-less replace buffer objects by a 'bytes' object, and to extend the
>buffer API with 'locking' (actually a different API that gives more control
>to the acted-upon object.) No buffer API deprecation, silently or not.
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/