Re: Gill, the Canvas, libart...

[Raph Levien <raph acm org>]

Lyndon Drake wrote:
> 
> Hi,
> 
> I maintain the Gnome interface for R, and in the near future I want to use
> the canvas for graphics output.  I have experimented with the canvas
> previously, and found that it did most of what I wanted.  Over the next few
> weeks, I want to do a proper canvas device for R, which will become the
> default graphics device for the Gnome version of R.

Sounds excellent.

> My initial attempt at using the canvas involved creating a canvas item for
> each graphics element (eg lines, circles, text).  This was a great way to
> use up lots of memory :-).  Someone pointed out that the Right Way to do
> this sort of thing was to create a new canvas item that used libart to
> render each of the elements.  Has anyone else started any work on something
> similar to this?  Is any of the stuff in Gill related?

First, what do you mean by "lots of memory"? The overhead for a Gnome
Canvas item object should be a few dozen bytes. In addition, the aa
renderers for Gnome Canvas items tend to cache a lot of svp's (sorted
vector paths). For simple shapes, these shouldn't take too much memory,
though.

If this kind of memory overhead is too much, then a custom canvas item
is certainly a reasonable approach - you can cut memory usage pretty
much down to the bone.

It sounds like what you're trying to do may be related to Gill, although
at present I'm not doing anything in particular to minimize memory
usage. Gill can handle fairly detailed graphics without problems
(especially on today's RAM-laden machines), but it's not impossible to
cause thrashing. Incidentally, Gill still has some memory leaks.

> 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
> that there is a nice PS driver in R, which makes writing a gnome-print
> driver a lot easier.  Plotting on the gnome-print driver would display on
> the canvas item, and users would then be able to print the completed
> output.

Sure. As Havoc points out, a gnome-print -> canvas preview is envisioned
for the fairly near future. This should work well, but of course the
main drawback is that you lose most interactivity.

> Is text fully functional yet on the anti-aliased canvas?  When I looked at
> it previously, clipping didn't work very well, and rotation didn't work at
> all.

No, the text implementation is pretty buggy. Rotation should work, but
there are _definitely_ clipping issues and other not-niceties.

I've been feeling a bit stuck on the text item for the gnome canvas,
because I'd really like to do an item that supports _real_ text. The
text item as it stands now is basically just trying to copy X text/font
support, which is a bit perverse. But even though I have a type1 font
converter, and plenty of code to do fun things like unicode->glyph
mapping, ligatures, kerning, hyphenation, and paragraph-optimized
justification, there are still a lot of issues about how to integrate
this properly with the rest of gnome. In particular, Owen Taylor is
presently working on an X-based Unicode engine for Gtk+, and I do not
want to duplicate effort of his.

I think Owen and I will come up with a unified text handling story soon
(code name Omniglot), at which point a good text item for the canvas
should flow nicely.

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

Right. This falls into the "damn this computer, I'd like to sell it; it
does not what I want, just what I tell it" category. In Gill, the
default coordinate system has the corners of a pixel falling on integer
grid points. This means that if you define a rectangle with integer
coordinates and fill it, you'll get sharp edges, and also if you define
a path stroked with a line width of an even number of pixels. But if you
stroke a line width of one pixel, you'll see the two 50% gray effect.
It's hard to do the right thing in all cases.

But for plots, you have a very simple solution, which is to transform
the coordinates so that the centers of a pixel fall on the integer grid
points, i.e. translate by 0.5, 0.5. Then, when you stroke lines centered
on integer coordinates with a line width of 1, you'll get the nice crisp
line you wanted.

> I am happy to work on a canvas item for doing the plots and a gnome-print
> driver for the canvas item, but it would be great if someone who
> understands libart was able to help.

I am very pleased that you're working on this, and am glad to provide
libart help. Libart and the Gnome Canvas are still very much works in
progress, and there are quite a number of issues to deal with. So please
bear with me if certain things aren't quite what they should be yet.

Raph