Re: Gill, the Canvas, libart...

[Lyndon Drake <lyndon stat auckland ac nz>]

On Thu, Jul 15, 1999 at 07:25:04AM -0700, Havoc Pennington wrote:
> Guppi is pretty darn related. I chose not to use libart for my custom
> items because it would be slow to update; but if quality is the main
> concern, you could use it. Just copy the stuff from the current canvas
> items to see how to use libart for the rendering.

I want to have an option (I don't know yet whether it will be dynamic or
not) as to whether to use libart or GDK.  libart looks so much nicer,
and does actually improve the readability of complex plots.  People on
8-bit X terminals or slower machines will probably want to use the GDK
version though.

> > I may use gnome-print for the graphics, and write a gnome-print item (like
> > the PS one) that displays on the canvas item.  The main reason for this is
> 
> I know Raph and Federico wanted to do a "print preview" sort of thing that
> would render via the gnome-print interface. I don't know if that would use
> the canvas or just a drawing area.
<snip>
> Frankly I see almost no reason to use the canvas for R; R is running in
> batch mode, you may as well just use libart or the 'mi' lib from
> guppi/plotutils to fill an RGB buffer, then copy the RGB buffer to a
> drawing area. Everything is in a single custom item anyway, there's no
> dragging or clicking on the plot (right?), so you gain nothing but bugs by
> using the canvas.

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.

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.)

> > I also noticed a couple of things were graphically incorrect with the
> > antialiased canvas.  Specifically, horizontal 1 pixel lines, instead of
> > being 1 black pixel high, ended up being two dark grey pixels high.  This
> > really sucks for the axes on plots.
> 
> 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.

Thanks,
Lyndon