On, Thu Aug 23, 2007, Lenard Lindstrom wrote: > 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 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... > 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? Regards Marcus
Attachment:
pgpaiapOgiyK0.pgp
Description: PGP signature