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