Re: [pygame] PixelArray question

["René Dudfield" <renesd@xxxxxxxxx>]

One thing to note is that we need to support the surfarray interface -
for backwards compatibility.


On 8/28/07, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
> I've been thinking about all this PixelArray discussion a lot, and
> I've come to think the following 3 things:
> 1. PixelArray would be better with another name, to make it clear that
> it isn't actually an array - it just provides array access to an
> existing surface's content, and such that the name makes it more
> obvious why [] access would work as it does
> 2. Explicit locking is better than having the PixelXXX object do
> automatic surface locking over it's lifetime - I think this because
> the automatic locking would be arcane and non-obvious, basically a
> side effect. I think that arcane behavior would be even worse cause
> locking won't effect SW surfaces, so people won't be getting feedback
> on whether the auto-locking is doing anything/working right. So in
> those very rare cases where you might need it (HW surfaces) you aren't
> likely to know it's even doing it, or to know what the gotchas that
> might break it are.
> 3. The with statement seems to be a neat way to manage locking the
> surface when you need it, because the code will be the most readable
> because it would actually tie the lock behavior to a scoping block -
> making all the pixel array access stuff that should be tied together
> actually look together
>
>
> On 8/22/07, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
> > I may have missed something, but why is a separate PixelArray class
> > necessary. Couldn't the array methods and buffer interface be added to
> > Surface?
> >
> > --
> > Lenard Lindstrom
> > <len-l@xxxxxxxxx>
> >
> >
>