Hi Jim.
> One comment on the comment. Isn't the upper bound on the ratio equal
> to sqrt(2)/2? The radius (lineWidth2) is never greater than this chord
> length for any angle >90.
You're right.
> When would the isCW test trigger? Does it track "rev"? What happens
> at 180 degrees (is that test reliable for the randomization that might
> happen when omxy are directly opposite mxy)?
isCw is used for computing the arc bisector by testing whether the computed
point is on the side it should be (and multiplying by -1 if not), it is used
to compute the sign of cv in drawBezApproxForArc, and for computing rev.
> The only reason I ask is
> because I think the sign of mmxy is probably controllable by
> understanding the input conditions, but this test should be safe
> (modulo if it really works at 180 degrees). If it has failure modes at 180
> degrees then reworking the math to produce the right sign in the first
> place may be more robust for that case. A test for this is to render
> "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate it through
> 360 degrees and see if the round caps invert at various angles.
I already did that. I drew 100 lines like the one you describe. I attached
the results. It never fails. It is still possible that there could be some
case where it fails, but this does prove that such a case would be very rare.
> Also, line 256 - does that track "rev"?
It does. I changed the test to if(rev).
> when you reach the end of my comment queue and I'll start the
> hopefully final proofread?
I made the change you suggested to the dasher binary search, so I'm almost done.
I still have to run some tests, but I should be done by today.
Regards,
Denis.
----- "Jim Graham" <james.gra...@oracle.com> wrote:
> Hi Denis,
>
> On 10/18/2010 2:21 PM, Denis Lila wrote:
> > I introduced a drawRoundCap method. This eliminated the side
> argument from
> > the round join drawing, which made it easier to eliminate the trig
> function
> > calls. I did this by using dot products to compute cosines (which
> was possible
> > because now Stroker takes only untransformed paths, and all
> lineWidths are the
> > same), and I used the double angle identities to compute any sines.
> > I came up with my own ways of detecting acute/obtuse angles and
> finding the centres
> > of angles ("my own" meaning I didn't look at any websites), and they
> consist of:
> > 1. if (omx * mx + omy * my)>= 0 then the angle is acute (line 200).
> > 2. I explain this in a comment in the file (line 208).
>
> The new trig-less round join code looks great! I don't see any
> errors,
> but a couple of nit comments:
>
> >> My head started spinning when evaluating the parallel curve methods
> so
> >> I'll stop here for now...
> >
> > Sorry about that. Is there anything I can do to make it easier?
>
> Actually I think I'm up to speed on all the math now. I mainly have
> to
> double check the bookkeeping stuff a second time. Can you let me know
>
> ...jim
