Re: Using libart_lgpl directly

[Raph Levien <raph acm org>]

Lyndon Drake wrote:
> 
> Hi,
> 
> I'm working on a graphics device for R, so that things like plots can
> be displayed to the user.  I have a working device that displays plots
> on a GdkDrawingArea, and I also wrote an experimental device that uses
> the canvas.  Using the canvas produces very nice looking plots, but it
> also uses up lots of memory (eg 10,000 points uses up about 40MB of
> memory).  I realise that the canvas wasn't designed with this sort of
> thing in mind, but I would like to be able to have nice anti-aliased
> plots.
> 
> What I am considering doing is creating a widget, similar to
> GdkDrawingArea in some respects, for displaying static,
> non-interactive graphics.  I envisage doing this by giving libart_lgpl
> a buffer or pixmap, and a command (eg. line_to).  libart could then
> render the line on the pixmap.  No information about the line would
> need to be kept, and the memory used to display the image would be the
> size of the pixmap.
> 
> Is it possible to use libart in this way?

Yes, but there are probably better ways.

> I am also unsure about whether to make the api similar to PS or gdk/
> X11.
> 
> I would appreciate some help with this, as the documentation for
> libart is a little limited, and I am having difficulty getting a good
> overview of libart's usage from the source.

Yeah, sorry about that. Real documentation for libart is planned, but
right now you pretty much have to RTFS, and the libart source is not
exactly transparent.

I'd recommend going one of two ways with this. Your first choice is to
implement a custom canvas item for drawing lots of points. This item
could simply store a big list of coordinates, so roughly 16 bytes per
point. Then, the render method would render it as appropriate.

You could save a little time by precalculating the svp for the "point"
shape, then translating it for each point before rendering. This way you
only need one svp for the item, rather than one for each point, which is
where the memory is being eaten right now.

Your second possibility is to wait for the RGB-rendered gnome-print
backend. This probably will happen pretty soon. Basically, you'd open a
gnome-print context coupled to an RGB buffer. You do drawing operations
very similar to PostScript operators in this context, and at the end you
have an RGB buffer, which you can easily display in a window. The
gnome-print api is designed to be quite consistent with PostScript - if
you have code to draw into PS, doing a gnome-print driver ought to be a
piece of cake. This is also a good way to print.

The disadvantage of the second method is that you have to either wait
for the code or start writing it yourself :)

Raph