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

Re: [pygame] no unlock: surfarray.pixels2d() and PixelArray() bug or intented?



On, Fri Jun 06, 2008, Marcus von Appen wrote:

> On, Fri Jun 06, 2008, Jake b wrote:
> 
> > version: pygame '1.8.0release'
> > 
> > When using pygame.surfarray.pixels2d( surface ) or pygame.PixelArray(
> > surface ) they both lock the screen surface, but do not unlock when done.
> > 
> > Is this a bug, or is it intended behavior? If so, why? It seems backwards to
> > me.
> 
> They need to be released or their definition scope has to be left. As
> both access the underlying pixels directly during their lifetime, an
> explicit deletion of them has to be triggered.

Regarding the why: Numeric/Numpy arrays directly operate on the
buffer. In this case it is the Surface's pixels part, which has to be
permanently available as we can not guarantee for the behaviour of Numpy
and Numeric in other cases.

PixelArray uses the same locking approach for the following reasons:
* a somewhat similar usage as surfarray 
* allow easy subclassing without the need to take care of locks
* avoid extensive lock/unlock calls on multiple operations of the
  PixelArray
* allow easy subarray access through multiple PixelArrays on one initial
  array.

Especially the last ones are important in scenarios like those:

  for ...:
      pixelarray[...] = ..

  for x in pixelarray:
      ...

  subarray = pixelarray[...]
  ...

Regards
Marcus

Attachment: pgpiVjeFXaKBN.pgp
Description: PGP signature