Re: Using libart_lgpl directly

[Havoc Pennington <hp Mcs Net>]

On Wed, 3 Feb 1999, Lyndon Drake wrote:
> 
> What is the advantage of writing a custom canvas item, instead of a 
> GtkDrawingArea like widget?

I was comparing it more to the "many canvas items" approach.

vs. writing a widget, a canvas item is probably easier, and you have 
more flexibility. For example, you can use the existing canvas items for
the axes or any overlays (for example, Guppi will probably use libezpaint
to let you place arrows and text on the plot). (libezpaint is on CVS under
'ezpaint'.) Widgets are more limited because they have to be rectangular
and can't overlap.

>  The direct to rgb buffer stuff seems to
> duplicate the functionality in gdk, 

It does, but it is faster if you're drawing a lot of points. Each call to
gdk_draw_point[s]() makes a server trip - "buf[i] = color" is much,
much faster than that. The speed hit for RGB is copying the RGB buffer to
the screen; but that hit is constant regardless of the number of points,
and is nearly instantaneous.

Eventually I plan to do things like:

if (number_of_points < small_number)
{
  /* use antialiased drawing */
}
else 
{
 /* Draw direct to buffer */
}

> and I believe it's possible to
> place arbitrary widgets on the canvas anyway? 

It is, but you can't overlay anything on top of them, and they have to be
rectangular.

> It just seems to me
> that what I want to do is quite different to what the canvas is
> for, even though it will use the same library for graphics
> primitives (libart).
> 
> I may have completely the wrong idea, so feel free to correct me.
> 

You're probably right - IIRC R draws to a "device" which is essentially a
static page, i.e. no user interaction. The canvas probably gives you
little to no advantage, except that it may be easier to use it than to
fool around with your own RGB-buffer widget.

> BTW, I noticed that the source is marked as C++ (thought I didn't
> notice any major C++isms).  I am restricted to C in my project, so
> it would be cool to have a C widget.
>

That particular file is basically all C, aside from some // comments and
the like. Easy to port to all C.
 
> Anyway, it would probably be a good idea to work together on this.
> 

I'm open to it though I'm not sure R and Guppi have the same requirements
- Guppi's plots will be more interactive, some kind of cross between Excel
and XGobi. However, Guppi will eventually have printing support and that
will work more like R, probably using the still-in-development gnome-print
stuff. And there are things in common, definitely.

You might look at gnome-print, it may well do something similar to what
you're looking for. If not now then soon. 

Havoc