As the ongoing discussion about PixelArray has shown, there is some confusion about how it will affect pygame.surfarray, which should fully implemented in python. First of all (and once again), PixelArray is _not_ meant as a full featured replacement for the arrays of Numeric and Numpy. All of its upcoming features are meant as an enhancement for those, who do not want to have Numeric or Numpy as a dependency for their pygame project, but need some better direct pixel access than the surface.set_at() amd surface.get_at() methods can offer. Back to the surfarray issues. As you might know, there were recent discussions about migrating to Numpy completely and to drop Numeric support as its development is stalled and no further upstream packages, bugfixes or whatever else will be made available for it. We cannot simply drop support for Numeric as this would possibly break a lot of projects which use pygame.surfarray and Numeric for pixel manipulations. Instead we decided on creating a new object type, which allows a direct buffer access, which then can be used by Numpy and Numeric. This allows us to get rid of the C implementation of surfarray and to move all of it into pure Python code. There will be no visible changes regarding the surfarray module and its methods besides that it is implemented in Python. Additionally developers should gain access to an easy to use buffer object, that allows them to use the pixel buffers of a surface in other libraries such as PIL. So how will the changed implementation work? Although not written yet, it'll basically do the following steps: * get exclusive buffer access (through locking) * pass the buffer to the Numeric/Numpy constructors * return the Numeric/Numpy array back to the user Numeric/Numpy hold a reference to the buffer object, thus it will be released, when the arrays are deleted (just as its done now). Depending on what the user invokes (array* or pixels*) either the read or read/write method of the buffer will be used, causing Numeric/Numpy to copy the buffer contents or to maintain direct access. They do that automatically, so there's no special treatment we or pygame users wouldd have to take care of (*). If the developer acquires the buffer for his very own purpose (e.g. PIL), he'll need to explicitly delete it. PixelArray was initially meant as that kind of buffer object, and I decided later on, that it'd be nice to spend it some more functionality such as slicing, 2D access and so on. As it turned out so far, those both purposes cause some confusion, thus I have to agree to Lenards and Brians suggestions of keeping the buffer access as a completely own (minimal) object type, while using the PixelArray object as own 2D accessor. (*) Numeric's python interface does not allow direct buffer access, instead it always does a copy. Rene however found some interesting piece of code, that works around that issue. We want to use that code internally to allow Numeric direct access. Regards Marcus
Attachment:
pgp92Ev92Ehg3.pgp
Description: PGP signature