[OpenJDK 2D-Dev] RFC: Fix for 7036754

[Jim Graham]

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.