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.
