[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>