One thing to note is that we need to support the surfarray interface - for backwards compatibility.
On 8/28/07, Brian Fisher <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> > > > > >
