Re: [pygame] PixelArray question

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

I'm not sure what you are saying here - do you just mean that the
surfarray module code will stay untouched? do you mean that surfarray
will use PixelArray for something so PixelArray needs to do that work?
or do you mean that PixelArray should implement some surfarray
functions so that it could be used as a drop-in replacement (i.e.
replace in .py files "surfarray" with "PixelArray" should work)?

in other words how does that relate to some PixelXXX class?

On 8/27/07, René Dudfield <renesd@xxxxxxxxx> wrote:
> 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>
> > >
> > >
> >
>