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

[Lauris Kaplinski <lauris helixcode com>]

Hello!

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

Well, I bet most people would appreciate, if you could find some web
space for screenshots and just post url here. Size considerations aside,
some people are telneting to their mail machines, and getting screenshot
back to work machine is quite inconvenient.

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

I would suggest:
MOVETO_OPEN (opening tic) LINETO (bar)
MOVETO_OPEN (bottom of bar) LINETO (top of bar)
MOVETO_OPEN (bar) LINETO (closing tic)
ART_END

Libart handles multipart paths well and you get rid of ugly 180 degree
turn.

Lauris