Hi Denis,
The strategy I took to work around this was to simply check for a zero
denominator in the Miter method and return the average of the endpoints
instead of the intersection points. That makes a straight line via a
quad that has colinear points, but it greatly simplifies the impact of
the fix.
To be safe (performance-wise), I made a separate copy of the method
called "safecomputeMiter()" and put the test only in that copy (which is
only used from the quad function) until I have time to do some more
exhaustive performance tests. To be honest, though, I don't imagine
that single test could affect performance (given that "den" is already
computed as the difference of two values, the subtract operation already
sets condition codes so it is simply a matter of how fast the processor
can take the branch or not, and this is likely a case where branch
prediction would pay off a lot...)
...jim
On 4/15/2011 10:38 AM, Denis Lila wrote:
Hi.
Jim Graham pointed out this bug to me.
A fix is here:
http://icedtea.classpath.org/~dlila/webrevs/7036754/webrev/
It just checks for inf/nan and just emits a line joining
the endpoints in that case.
The stroking is no longer symmetric with respect to right
and left polynomial degrees. This is a bit more general.
I have a question:
The "curve is a straight line" check I use is this:
737 float dotsq = (dx1 * dx3 + dy1 * dy3);
738 dotsq = dotsq * dotsq;
739 float l1sq = dx1 * dx1 + dy1 * dy1, l3sq = dx3 * dx3 + dy3 * dy3;
740 if (Helpers.within(dotsq, l1sq * l3sq, 4 * Math.ulp(dotsq))) {
However, this isn't making much sense mathematically
right now. I would like to avoid redoing the math
so if someone can quickly confirm/deny that it works
that would be nice.
Thank you,
Denis.
