Re: [Pysdl-devel] slice operation, numpy, speed

[Pete S. <pe...@sh...>]

> I've not used "Numerical Python", but here's a few things to consider:
> The manipulation of multidimensional chunks of surfaces is already handled by
> blitting.
> Numerical Python may offer something other than array operations, but if that's
> all it does, it's not going to help per-pixel manipulation.
> The rest of Python's math is abysmally slow. This is the price of implementing
> integers as objects, and requiring several function calls and conditionals for
> each operation.

Numeric Python speeds this up by forcing all members of the array
to be the same type (although it does allow arrays of PyObjects).
Some of the operations are not 'intuitive'. the documentation
is good, but everything is still pretty 'technical'.

I've been thinking about the best interface between numpy and sdl.
for now i'm thinking stuff like get_array to complement get_at, etc.
at that point i'll really be able to test out the speed and see if
it's worth extending further and/or committing with the offical pysdl.

down the line i think the best interface would be creating a
new class, pysurface(?). it would be a wrapper around the numpy
array and offer the same calls as the current surface object.

the other neat thing about the numpy array is it can be accessed
from their C API as a simple C array of whatever datatype it is.


> A command buffer for operations will most likely be a bit of work. It'd
> probably be a bit awkward in comparison to what people are generally used to
> as well, in order to make it efficient.

do you imaging the buffer caching all blit and get_at, set_at style
operations? perhaps it would be a class that takes a surface object
as an initializer. then you call the standard surface operations on
it which end up putting a function object into a list. then some call
like commit() or flush() would just execute every function on the list?
hmm, i haven't thought the whole thing through, but it seems something
like that might be the way to go.
better yet, the commit() function could take an argument of the surface
to operate on. then you could just build a bunch of these command lists
and call them when needed.
(maybe taking an image and on x,y offset as args?)

 
> Before that, though, I think I'll work on some drawing primitives for the
> existing surfaces. Circles, lines, etc. We'll see.

cool. i think there are already some SDL libraries for doing this.
are you leaning towards our own implementation, or another dependency?

whew! enough mail from me, i need lunch!