[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PixelArray question



Marcus von Appen wrote:
On, Thu Aug 23, 2007, Lenard Lindstrom wrote:


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

As I wrote in another mail, we do not know exactly, when the buffer is
released. We also cannot rely on the reference decrement - it'd mean to
lock the surface each time a increment will be made. Pretty bad...


I am very confused. I thought the buffer interface was on PixelArray, not Surface. Since PixelArray acts like Numeric/numpy, locking its parent while alive, it is the natural place for the buffer interface. I was also confused about the buffer protocol in general. I thought it always involved a buffer type instance.

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)?

Explicitly unlocking would mean calling unlock (and maybe lock) for
about 90% of the offered functions. I do not think that this is an
option.

What do you mean with context management exactly here?


I am still somewhat confused.  This is your example:

       sf = pygame.Surface ((10, 20))
       sf.fill ((0, 0, 0))
       buffer_request (sf)
       sf.unlock()


I will try and give a context managed version:

   sf = pygame.Surface ((10, 20))
   sf.fill ((0, 0, 0))
   with PixelArray(sf) as p:
       buffer_request(p)

The PixelArray __enter__ method simply returns self. __exit__ unlocks the parent surface and invalidates the array.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>