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

[Jim Graham]

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.