Re: [LIBART] Working on new canvas item...
- From: "James K. Wiggs" <wiggs novum-millennium org>
- To: Raph Levien <raph acm org>
- Cc: gnome-list gnome org, libart gnome org
- Subject: Re: [LIBART] Working on new canvas item...
- Date: Fri, 27 Oct 2000 01:04:13 -0700 (PDT)
On Fri, 27 Oct 2000, James K. Wiggs wrote:
>
>
> On Fri, 27 Oct 2000, Raph Levien wrote:
>
> > "James K. Wiggs" wrote:
> >
> > > ...
> > > gnome_canvas_item_update_svp_clip( item, &pbar->svp,
> > > art_svp_from_vpath(vpath2), clip_path );
> > > ...
> > >
> > > How do we set the "width" of the strokes that libart uses when
> > > rendering its vector paths?
> >
> > You need to be calling art_svp_vpath_stroke() rather than
> > art_svp_from_vpath(). That has the line width and other options. The
> > wierd behavior you're seeing is because the render routines don't handle
> > unclosed paths gracefully at all. Fortunately, the output from
> > art_svp_from_vpath is always closed (modulo some known numerical
> > stability bugs).
>
> Hmmm. Should I explicitly start the path with an ART_MOVETO_OPEN
> instead of an ART_MOVETO, given that it is an unclosed path? Or will
> it make any difference?
>
> > Hope this helps.
Yes, actually, it helped quite a bit. I'm getting things that look
more or less like a pricebar now, but still getting the occasional one
that has a large block attached to it. I suspect this is related to
the debugging output I'm getting along with it, where I'm getting a
bunch of messages of the form:
colinear!
colinear!
x_order_2: colinear!
x_order_2: colinear!
colinear!
colinear!
x_order_2: colinear!
x_order_2: colinear!
x_order_2: colinear!
x_order_2: colinear!
x_order_2: colinear!
x_order_2: colinear!
x_order_2: colinear!
x_order_2: colinear!
And so on. These appear to be coming from subroutines contained
in the file art_svp_wind.c, but I can't clearly tell what those two
routines (x_order and x_order_2) are doing. Now, the problem may
be due to the values I'm passing to art_svp_vpath_stroke(), also.
I'm using:
art_svp_vpath_stroke( vpath2,
ART_PATH_STROKE_JOIN_MITER,
ART_PATH_STROKE_CAP_SQUARE,
pbar->width, 1.0, 1.0 );
I simply dropped in 1.0 for the miter_limit and flatness values,
not knowing what would be rational numbers. Given that the object
I'm drawing is just a set of straight lines, which will always be
rectilinear, what would be the cleanest and most efficient values
to pass, here?
> > Raph
> >
> > --
> > Raph Levien <raph artofcode com> | artofcode LLC | www.artofcode.com
best,
Jim Wiggs
wiggs wiggs net
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]