[OpenJDK 2D-Dev] CubicCurve2D.solveCubic and containment/intersection bugs.

[Jim Graham]

Also, on the testing of the return value, I wouldn't bother with testing 
"% 2".  If you look at Path2D it just assumes that it is an even number 
(or the INTERSECT constant) and does the test based on whether it is 
INTERSECT or non-zero (for WIND_NON_ZERO which is compatible with 
CubicCurve and QuadCurve - I don't think there can be interior holes in 
a either single curve's outline)...

			...jim

On 1/12/2011 6:00 PM, Jim Graham wrote:
> One general comment about the new helper method. I probably wouldn't
> bother loading the control points into local variables since you only
> use them once in the function. It might be wasted effort if the cubic
> function isn't called, and meanwhile you are forcing the compiler to
> find some local storage to stuff them into for no good reason (the
> compiler can't optimize those fetches out or around since it has no
> concept of the potential side effects, or lack thereof, of calling the
> abstract getters)...
>
> ...jim
>
> On 1/12/2011 2:33 PM, Denis Lila wrote:
>> Hi Jim.
>>
>>> I replaced that test with
>>>
>>> if (!getBounds2D().contains(x, y, w, h)) {
>>> return false;
>>> }
>>>
>>> and that fixed both the bug and the performance of (1) without making
>>> (3) worse.
>>
>> It turns out that that test actually slows it down a bit. It was helping
>> us when we were using the PathIterator, but after the introduction of
>> the rectCrossings method you suggested, it's faster in all cases (even
>> (1))
>> to just do the general thing all the time. I've updated the webrev
>> with this.
>>
>> Eliminating the PathIterator also had a large impact on the
>> intersect(rect)
>> method. Now it's about 20% faster in cases (1) and (3). (2) is still
>> slower
>> but only by a factor of 2-3. Here's the webrev for it:
>> http://icedtea.classpath.org/~dlila/webrevs/intersectsFix/webrev/
>> I think the reason (2) is slow is because rectCrossingsForCubic
>> recursively
>> searches through subdivisions of the input curve starting at t=0 and
>> in increasing t. Do you think it would be worth it to switch the order
>> of the recursive calls depending on the distances of the two
>> subdivided curves relative to the rectangle (so that perhaps we would get
>> to the subdivided curve that crosses one of the rectangle sides sooner)?
>>
>> Regards,
>> Denis.