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.

Reply via email to