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

[Mark B. <mb...@0x...>]

On Sat, 03 Jun 2000, Pete Shinners wrote:
> 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'.

Could you explain where this will be beneficial?

> 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.

Why exactly would you create a new surface type, to use this array?
PySDL's surface object utilizes SDL's SDL_Surface. Its pixel data is just a
block of memory, either allocated from the heap, or mapped from a video card.
All of the routines involving the manipulation of pixel data directly access
this memory.
I'm simply having a hard time attempting to determine how this will help.
Someone please open my eyes.

 
> > 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?)

I was thinking of a command object that has surface methods. It could
then convert these methods into some binary format, which then could be
interpreted when the command object is 'executed.'
I've been tossing some other ideas around, as well, but their interfaces aren't
as intuitive.

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

I think most of these libraries also implement functionality we already have,
or have already gotten from companion libraries. I'ven't really decided. For
just simple primitives, the algorithms are simple, but I'ven't made any formal
decisions.