Subject: Re: FYI: librsvg
From: Justin Bradford (justin@ukans.edu)
Date: Tue Jul 25 2000 - 16:34:43 CDT
On Tue, 25 Jul 2000, Leonard Rosenthol wrote:
> Rather than reinvent the wheel, we should probably look at bringing
> it over to replace the work that Justin did, since it's much further
> along in actually rendering SVG.
Well, I had no intention of writing a complete SVG renderer, but if we can
make use of librsvg, that would be even better. I have the SVG parsing
code mostly done, but have been stalled by the limited XP graphics context
which Abi currently has (lines, rects, and polygons), and that's a much
bigger project than parsing style lines.
Also, I know that Raph has done some work on the FreeType code while
working on librsvg, and pending a modern GUI for unix, it would be
interesting to see if we could simply back the unix gr_Graphics with
libart and freetype. We would need to be better about redrawing only dirty
areas than we are now, but it would seem to me that the performance would
still be ok.
If you want to drop in librsvg, here's how I would do it:
1. Each gr_(platform)Graphics.cpp has a function drawImage, which
has platform specific blitting code. Move the blitting code into the
platform specific raster image class (in a render() method, like the
vector image class), that way the Graphics context can treat images the
same, and the image code is self-contained.
2. Put the librsvg-using code in gr/xp/gr_VectorImage.cpp, whenever the
data (SVG bytebuf stream) is set, or the display size is changed, have it
render the SVG to a new PNG. Then, inside the VectorImage class, create a
a raster gr_Image (of the appropriate platform type), give it the PNG, and
then whenever the Graphics class asks your VectorImage to render itself,
you just call rasterized->render(...);
Justin
This archive was generated by hypermail 2b25 : Tue Jul 25 2000 - 16:34:50 CDT