Re: [pygame] PixelArray question

[Lenard Lindstrom <len-l@xxxxxxxxx>]

Marcus von Appen wrote:
> On, Thu Aug 23, 2007, Brian Fisher wrote:
>
>   
[snip]
> > 2. There may be some design and implementation issues with it that
> > someone who actually wrote PixelArray could see... ?
> >     
>
> See the purpose, user expectation and recognition discussion we had so
> far, when it comes to design. One big implementation issue might be the
> buffer interface and locking we need for it. As it is uncertain at which
> time the requester of the buffer does not need it anymore, we have to
> rely on the user's explicit unlock (by using del array or in your
> example a call to sf.unlock():
>
>         sf = pygame.Surface ((10, 20))
>         sf.fill ((0, 0, 0))
>         buffer_request (sf)
>         sf.unlock()
>
> Looks a bit silly to me - and I would not expect that I have to do it :-).
>
> Regards
> Marcus
>   

A buffer instance has a reference to the owner of the data. I would 
assume that anything savvy enough to request a buffer will hang onto the 
buffer until it has finished with the data, then release it. Anything 
else probably expects a string, which is a copy of the data. But there 
was a big discussion not so long ago on comp.lang.pygame about relying 
on garbage collection to release a resource. Maybe all locked surfaces 
should be explicitly unlocked. Should a PixelArray support context 
management (with statement)?

--
Lenard Lindstrom
<len-l@xxxxxxxxx>