Re: [Pysdl-devel] Greetings.

[Martijn F. <fa...@ve...>]

Mark Baker wrote:
> Sorry for the somewhat superfluous message, but I just created this list, and
> I am curious if everything is functioning properly.

It works! :)

> That said, are there any pressing issues with the current release of the
> module?

Not yet. I haven't bashed it a lot yet; just the graphics part too,
so I can't say much about it yet. I'm building a higher level interface
to SDL now (in C, partially prototyped in Python), which I hopefully
can eventually contribute to PySDL. Currently my 'high level interface'
can only draw horizontal and vertical lines, though. ;)

The basic interface from Python I'm thinking about is something like this:

* In Python, have a 'Canvas' class. Using methods like hline, vline, line,
rectangle and a host of others we can come up with, you send 'commands'
to a canvas object, which are _not_ immediately executed. Instead they're
stored in a simple stack (commands and parameters..perhaps two stacks).
The commands are location insensitive; you can only use relative coordinates.

* When we're ready preparing the Canvas, we prepare the command stack
and possibly even optimize it. For instance, if we're drawing a line
two times in the same place, we might optimize one out, etc. This could
of course get very tricky, but at least we can do the analysis in Python.
Another option would be scaling up and down the entire picture.

* Then we send the list of commands out to C, and tell it where on an
SDL_Surface we want to draw all the stuff. Since the coordinates were
all relative, our picture is relocatable. C code then does things like
locking the surface if necessary, calling all the functions (highly
optimized for the particular colordepth), and updating the right area on
the surface. Poof! We can of course do this same drawing operation
multiple times.

* If we really want to speed of drawing, we can make a blittable sprite
out of our little Canvas once, and blit that to the screen direct, instead
of doing the same drawing again.
 
Of course I didn't profile before I optimized, so I don't really know
if the performance gain from this approach (when used from Python) will
be worth it. It should avoid most of Python's function call overhead, and
also repeated locking and unlocking surfaces in SDL. And repeated querying
of colordepth info, as I have a separate set of C functions for each
colordepth (which will all be untested but for 16 bit color as that's what
I'm running on, but okay :). But at least it'll be fun puzzling it out. :)

Regards,

Martijn