[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PixelArray question

Marcus von Appen wrote:

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. 
Yes. I certainly made things interesting. :-)


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.


I understand this as well.


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.
Reducing the need for surfarray is good. I just wonder if PixelArray is the only place where slicing and mapping could be done. Slicing, for instance, could be a feature of the Surface fill and blit methods. They would take optional x and y step values. The blit method could also have additional blend options for color/alpha channel copying. 


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?



Yes, that is slick.


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.
An whole Numeric/numpy replacement would be overkill. But as it stands, there is just no other way to do basic effects like shadows without them. 

--
Lenard Lindstrom
<len-l@xxxxxxxxx>