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