[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PixelArray question



ah, I mean we need to make a surfarray module with the PixelArray
module - so that the surfarray keeps backwards compatibility.

So the plan is to make a python module which uses PixelArray to make a
surfarray compatible module.

On 8/28/07, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
> 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>
> > > >
> > > >
> > >
> >
>