Hello Jim. > So either it is always on the right side, always on the wrong side > (i.e. just reverse the rotation in the math), or always on the right/wrong > side depending on the CWness of the join angle - which would be > reflected in rev... No?
That's a good point. I've changed the test to simply if(rev) because the normal we compute is on the left of the original vector (omx,omy)-(mx,my). So, if the arc was counter clockwise no adjustment was needed. Regards, Denis. ----- "Jim Graham" <james.gra...@oracle.com> wrote: > Right, but it seemed to me that if omxy was the "from" vector and mxy > > was the "to" vector, that the computed mmxy should always be > predictably > on the same side of it, no? If it was on the wrong side then it > wouldn't be a random occurence, it must be related to the input data. > > ...jim > > On 10/20/10 10:29 AM, Denis Lila wrote: > >> Cool, but above I was also asking the same question about line > 231, > >> and you provided a lot of information about line 231 (and a test to > verify > >> it), but didn't answer if the test in line 231 also tracks rev the > >> same way...? > > > > Oh, no, line 231 isn't mean to be related to rev at all. It just > checks > > to see on which side of the (omx,omy),(mx,my) chord the computed > (mmx, mmy) > > is. > > > > Regards, > > Denis. > > > > ----- "Jim Graham"<james.gra...@oracle.com> wrote: > > > >> Hi Denis, > >> > >> One clarification: > >> > >> On 10/20/10 7:11 AM, Denis Lila wrote: > >>>> 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). > >> > >> ...jim