PixelManipulater??? I don't know, it seems like it could fit. You have direct access to the pixels and manipulate them.
On 8/28/07, Marcus von Appen <[EMAIL PROTECTED]> wrote: > > On, Tue Aug 28, 2007, Brian Fisher 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 > > Yes, that's something I fully agree to (and strongly promote Greg's > "PixelArrayView", which fits well in my opinion). > > > 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. > > Let me get that right - on the one hand easy usage, on the other easy > pits to jump into. Although explicit locking might let us support the > with statement (which does not seem to fit for the PixelArray and > automatic surface locking), it burdens the user with a lot of > problems. He has to take care of locking in the one case while the > surfarray module would have to take care of it automatically (due to > backwards compatibility). That does not look straightforward to me. > > He also'd have to take care of a bunch of other issues such as explicit > deletion with a guaranteed ref count of 0 _and_ unlocking - otherwise > exceptions or other unwanted side effects might be raised. > > Thus I am strongly against that. Automatic locking - although it breaks > with the with statement (which is badly designed for such a purpose in > my opinion) - reduces the sources of errors for the developers here. > > > 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 > > Only, if it would destroy the object once the with scope is left. The > PEP did not say that much about the object's lifetime (maybe I overread > that), but as your example demonstrated, nothing will be cleaned up > afterwards. > > Regards > Marcus > >
