Re: [LIBART] Working on new canvas item...

["James K. Wiggs" <wiggs novum-millennium org>]

 Folks,

   One or two questions of a more general nature.  I expect that I'll
be posting a lot of questions to these lists over the next month or so,
and I'd like to avoid becoming a pain.  I tend to be fairly verbose and
descriptive in my posts, giving as many details as I can.  I *also* tend
to avoid editing a lot of the content in the follow-ups.  I do this
deliberately; I find that when I'm searching the archives for postings,
it often requires a lot of work because people clip so much information
out of the followups that you have to search back through multiple older
entries in the threads just to understand the issues being discussed.  As
a relative "newbie," I find myself wishing people would keep more of the
context of the original posts and the ensuing discussion.  I'm sure there
are people who disagree; if those people are the majority, and would
prefer that I trim my posts more, I suppose I'll have to do so.

   The other question is: would there be a problem with me including
screenshots to help illustrate the problems?  I would only post shots
of individual windows, and the size of them would likely be no more
than 15-20K; still, I could see people having a problem with that.  I
think that, when debugging an application that produces graphics, the
old saw about a picture being worth a thousand words is pertinent.  If
I can add a picture of the bad results, it seems that it might be very
helpful to the people who are trying to answer those questions.  But I
*don't* want to do it if it is going to upset a lot of people who may
be on low-bandwidth (or, heaven forbid, metered!) connections.

On 27 Oct 2000, Lauris Kaplinski wrote:

> Hello!
> 
> > >    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?
> 
> It should make a difference, although I am not 100¨† ¨†@ure, how libart
> handles stroking closed paths whose start != end. Anyway, ART_MOVETO_OPEN
> is certainly the right thing.
> 
> >    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!
> <snip>
> 
> Try inserting:
> 
> perturbed_vpath = art_vpath_perturb (vpath);
> 
> Before stroking your vpath. Libart (at least the one distributed with
> gnome-libs) is not always happy with straight
> horizontal/vertical lines - perturb make these slanted, adding
> microscopic disturbances to points.

   Tried this, and while it did in fact make those error messages go
away, it *also* made the vertical bars on my pricebars go away.  Hmm.
Does the ordering of the strokes make any difference?  As it is, I do
a MOVETO_OPEN to the beginning of the opening tic, then a horizontal
LINETO to the center bar, a vertical LINETO down to the bottom, then
a vertical LINETO up to the top, another vertical LINETO down to the
level of the closing tic, and then a horizontal LINETO over to the
end of the closing tic.  Then I put the ART_END point on.  Is there
some better ordering that I should use?  I suppose I could retrace
the entire set of steps back to the beginning and make it a "closed"
path, but it seems like a waste of CPU to do it.  I really want this
code to be *fast*.

> >    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?
> 
> Those shouldn't make any difference.
> Miter-limit is minimum angle between segments, with results mitered
> join. Usual is 11.0 or similar - that gives visually pleasant picture,
> without long triangles stretching out from picture.
> Flatness should determine, how well rounded corners and endpoints
> are generated. Usual value is 0.25 - but is you have miter/bevel/square/
> butt it does not make difference.

   You're right.  I tried multiple different values for each, and saw
no visible difference.  I'd settled on values of 15 and 0.5, because
I saw them used in some other code that I thought was at least fairly
close in purpose to mine.

> Lauris
> 

   Thanks again for your help, Lauris.


best,
Jim Wiggs
wiggs wiggs net