Re: [pygame] SVG and SDL/pygame with pycairo?

[Rene Dudfield <renesd@xxxxxxxxx>]

this sounds really good!

Definitely for after 1.7.1 though.

If pycairo has a tostring() method, then the Surface.frombuffer()
could be used to make the surface really quickly.


On 7/28/05, Bob Ippolito <bob@xxxxxxxxxx> wrote:
> 
> On Jul 28, 2005, at 12:02 AM, Terry Hancock wrote:
> 
> > On Tuesday 26 July 2005 03:17 pm, Shandy Brown wrote:
> >
> >>> I know that 'libsvg-cairo' is supposed to have an SDL
> >>> back-end renderer and 'pycairo' is the python binding for
> >>> Cairo.  It should certainly be possible in C, but I was
> >>> hoping you could just do it in Python, and wondered
> >>> if somebody knows for sure (and how to do it).
> >>>
> >>> Am I at least on the right track if I want to render SVG
> >>> "cels" to SDL surfaces for animation?
> >>>
> >>
> >> If you find out a conclusive answer please let me (and the list)
> >> know.
> >> The ability to do this would be ideal for one of my projects.
> >>
> >
> > Update on my quest ...
> >
> > It appears that "pycairo" may be a bit of a red herring. Cairo is
> > a general-purpose vector graphics engine, and rendering SVG
> > with the libsvg-cairo package is only one small piece of
> > functionality.
> > Pycairo is more like a drawing library for Python.
> >
> > There is an example in the Cairo CVS of rendering an SVG file
> > directly to an SDL surface.
> >
> > http://cvs.cairographics.org/cairo-demo/sdl/
> >
> > I think the easiest way to make this work is to write a  Pyrex module
> > around that demo.  Then I need to know how to wrap the resulting
> > *SDL* surface  in a *PyGame* surface (which is presumeably not
> > hard, but I'll need to look at the PyGame sources to figure it out ---
> > probably have to call a PyGame extension module from Pyrex?)
> >
> > I don't presently know how to do that, but I just downloaded the
> > PyGame sources to look.
> 
> src/pygame.h and src/surface.c .. in particular, PySurface_New is
> exactly this.
> 
> > Assuming that I do this, is this something desireable enough that
> > people would like to see it incorporated into PyGame? It's probably
> > a bit small to distribute on its own (hopefully it's <100 loc), and if
> > I just incorporate it into my application, it won't be as easy to
> > reuse.
> 
> I think it sounds like a good idea for 1.8.  However, it'd probably
> be best if it was plain old C rather than Pyrex code.  Though,
> something that works is better than nothing, it's just that Pyrex
> extensions are a bit harder to debug and sometimes the pyrex source
> and generated C end up out of sync.  There's also no other generated
> code in pygame at the moment.
> 
> -bob
> 
>