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

[Jim Graham]

Oh, and you changed the length of the method name, but didn't change the 
indentation of some of the continuation lines.

(Picky, picky, picky, ;=)

			...jim

On 4/18/11 12:05 PM, Denis Lila wrote:
> Hi Jim.
>
>> Hm. It turns out that if the parallel versions of the control
>> lines are extended to infinity, their intersections form a
>> rhombus whose centre is the second control point (i.e. of the
>> centre curve). The control points we're trying to compute are
>> two vertices of the rhombus that lie on the same diagonal. An
>> equation for this diagonal would be c2 + t*( (c3-c2)/||c3-c2|| +
>> (c1-c2)/||c1-c2|| )
>> where c1, c2, c3 are the control points of the centre curve.
>>
>> To compute the points we want we would need to know their distance
>> from c2.
>
> This is pretty easy to do, but it involves a few too many sqrt
> calls.
>
>> Well, thanks for getting me thinking about this. This line of
>> thinking seems promising.
>> I'll try to code it up.
>
> This wasn't fruitless, however. It made me realize that
> if we have the second control point for the left path
> we can compute the second control point for the right
> path with just two subtractions and 2 multiplications:
>
> http://icedtea.classpath.org/~dlila/webrevs/7036754/webrev/
>
> Is that good to go?
>
> PS: I made some other changes: one style fixup (a "{" was not
> following our convention), removing "Math." from certain
> calls using "include static", and fixing comments that didn't
> make sense.
>
> Thank you,
> Denis.
>
> ----- Original Message -----
>>> 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
>>
>
>>
>> Regards,
>> Denis.
>>
>> ----- Original Message -----
>>> Here's an odd thought.
>>>
>>
>>>
>>> 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.