On, Thu Aug 23, 2007, Lenard Lindstrom wrote:
> Marcus von Appen wrote:
>> On, Thu Aug 23, 2007, Lenard Lindstrom wrote:
>>
>> [...]
>>> As for slicing, that is just a generalized form of Surface.subsurface
>>> (with the parent locked for consistency with surfarray). But I appreciate
>>> that time constraints prohibit adding something like strides to a
>>> subsurface.
>>
>> It is a bit more than a plain subsurface as soon as mapping is working
>> as supposed. You cannot create a subsurface using e.g. every second row
>> (or column) of a Surface, you will be able to do that with the
>> PixelArray however.
>>
>>
>
> No, I don't expect anyone to make subsurfaces non-contiguous. But I do have
> a question about the expected use-cases of PixelArray. Obviously it
> provides a buffer protocol. But I am wondering where the slicing will be
> used? Personally I find a 2d array of raw pixel values not very useful.
> Alpha channel manipulation is awkward.
> surfarray.pixels_alpha/surfarray.array_alpha are much more practical with
> 32 bit surfaces. 3d arrays allow easy color plane separation. I guess I
> lack the experience to see how PixelArray slicing fits in.
It's especially made to get rid of the numeric/numpy issues we ran into
lately. I guess you followed the discussion about the numeric to numpy
switch, backwards compatibility and the need to explicitly install
numeric to have surfarray support.
The buffer support allows us to move (nearly) the whole surfarray code
into plain python, thus making pygame independent of numeric and numpy
at compile time. Additionally the user has a greater flexibility of
using numeric or numpy for _really_ fast or complex array operations,
ufuncs and arithmetic operations.
The integration of slicing, mapping and other features I mentioned
before surely might look superfluous to those who extensively use
numeric and numpy to do fast (or complex) operations on the pixels of a
surface. It allows you however to have a small feature subset which -
for most easy operations - allows you to stay independent of numpy and
numeric thus not requiring users to install them either.
Additionally it will give you some extra features such as the mentioned
tiling or cropping with creating a new Surface based on the original
contents and no need to do additional arithmetics.
newarray = array * 4
for example could create a new surface containing 16 tiles of the
original one. To use the new surface
sf = newarray.surface
del newarray
screen.blit (...)
is a pretty handy way, not?
My intention never was (and surely will never be) to implement a whole
numeric/numpy replacement, not at last because both (especially numpy)
have a great depth (numpy for example offers bindings to lapack, one of
the fastest math libraries available), which to implement would go too far.
Regards
Marcus
Attachment:
pgp8c2U3bZoSu.pgp
Description: PGP signature