Re: Gill, the Canvas, libart...

[Raph Levien <raph acm org>]

Lyndon Drake wrote:
> Based on what you've said, I should probably go for using a drawing area
> rather than the canvas.  I hadn't really considered using libart
> independently, but you are right in that I don't really want any of the
> canvas's interactivity stuff, so there is little point using the canvas.

Right. libart + a drawing area would be a perfectly reasonable approach,
and you'd certainly be able to minimize memory usage easily (by the
simple expedient of freeing structures once you're done using them to
render).

You might find that the canvas has certain advantages anyway. For one,
it's simply easier to program. You'll get certain things, like zooming
and scrolling for free. You'll be able to composite with other things
that use canvas items. Finally, even though R is batch-based now, you
(or someone else) might find the interactivity a tempting itch to
scratch.

> The only thing with using libart directly is that there isn't an easy
> way to do text.  I've had a look at what the canvas does, and it looks
> like it grabs a pixmap of a glyph, and then copies pixels into a
> libart buffer.  The documentation for t1lib says that it does
> antialiasing by "subsampling with factor 2 or 4 alternatively".  Is
> this the same, better or worse than what is done through the canvas
> text item?  (I've just noticed that Raph Levien is credited with the
> antialiasing in t1lib, so I guess it's probably the same.)

That kid gets around, doesn't he? ;-)

There are of course a few different ways of doing text in libart. The
current canvas text item does it by grabbing glyphs from the X server,
then displaying them stupidly (i.e. without even antialiasing).

You can also get text from t1lib and use libart to composite it with the
image.

Finally, you can convert type1 fonts into bezier paths, and use libart
to render them as bezier paths. There is a type1 parser currently in
Gill, and this is the approach I'm going to use in Gill. The libart
rendering of bpaths achieves higher quality than the t1lib approach of
rendering a higher resolution bitmap and subsampling down, and can
potentially be faster, especially for large glyphs.

So this is what I'm going to do for the "real text" Gnome Canvas item,
i.e. the one that gets used in Gill to render SVG text. I'm also going
to play with caching of pre-rendered antialiased glyph data, in an
attempt to speed up the rendering in the case where you've got lots of
text. But it sounds like for your application, this caching is not
critically important.

> > This is the antialiasing; that line is deemed to be between two rows of
> > pixels so gets spread among them. If you want crisp lines, use X-style
> > primitives (Guppi comes with these, you can copy the library, also GNU
> > Plotutils where I originally got the library now comes with a more
> > featureful version.)
> 
> If it were just the plot axes, I could just draw them using GDK, and do
> the rest of the plot using libart.  However, horizontal lines occur in
> plots as well, and it really sucks if they get blurred.  There must be a
> way to fix libart's antialiasing so that this doesn't happen.

I would recommend tweaking the coordinates so the outline of the line
fits exactly on integer grid coordinates (as opposed to the center).
This way, you'll get the crispness you're looking for, without the
hassle of mixing Gdk primitives and libart.

One approach that might work is to do the equivalent of "hinting", ie
recognizing horizontal and vertical single-pixel strokes, and doing a
rounding operation on the coordinates so as to make the lines render
more crisply. You'll want to trade this off against loss of accuracy. In
the case of axes and tics, you have the option of setting the offset and
scale so that these lines just "happen" to align with pixel boundaries.

Let me know if there's anything else I can help you with.

Raph