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

[Jim Graham]

Here's an odd thought.

For parallel quads, is there a relationship between any of the following 
points that could be exploited?

original control point
left_curve and right_curve control points
center point on the original (and rt and lt) curve
perpendicular of center point on the curve(s)
center of line between endpoints

I'm just basing this on a "gut feel" of how quad curves behave, not on 
any mathematical intuition, though.  It also makes sense given that you 
are computing the intersection of parallel versions of the lines.  I'm 
guessing that the intersections of all parallel lines equidistant from 
the original pair form a line themselves and that line might be related 
to other points we have access to.

But, it might be some food for thought on how to make parallel quads go 
a lot faster...

			...jim

On 4/15/2011 2:20 PM, Jim Graham wrote:
> 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.