Hi Denis,
I'm all in favor of simplification by using the new crossings code. I
originally balked at using it because I thought it might be slower, but
I didn't do any benchmarks to back that up. Have you benchmarked the
changes at all?
BTW, I would replace rectCrossings(getPath().getIterator()) with a
utility function that calls the rectCrossingsForLine/Cubic() methods
directly for the 2 elements of the path. (Remember to check if
crossings is RECT_INTERSECTS after the first call as that is a
short-circuit answer.)
...jim
On 1/11/2011 2:48 PM, Denis Lila wrote:
Hi Jim.
so it's behaving correctly (at least in this case)
However, contains(Rectangle2D) was still broken, because it
made the assumption that the line joining the endpoints splits
the cubic curve into two convex curves. This is not true - I've
attached a picture that illustrates why not (the reproducer for
4724552 also contains a curve that breaks contains(Rectangle2D)
in the same way).
I've made a first attempt to fix these two methods in:
http://icedtea.classpath.org/~dlila/webrevs/intersectContains/
I'm still not completely clear on how contains and intersects are
supposed to behave in corner cases, so I made the webrev as simple
as possible by ignoring any optimizations that might have been
possible. We can put these in later.
Am I missing anything?
Thank you,
Denis.
----- Original Message -----
Hi Jim.
I'm starting a new thread about this, since "X11 uniform scaled
wide lines and dashed lines; STROKE_CONTROL in Pisces" has
absolutely nothing to do with what we were discussing :-)
You might want to submit it as a separate push and get credit for
fixing
4645692 (solveCubic doesn't return all answers), and maybe even the
following failures in the containment methods (which could be closed
as
dups if this fixes the problems) as well:
4724552
4493128
4074742
4724556
(etc. Those were just the bugs I found on the first 2 pages of a bug
database search)
I've been thinking about these bugs, but I'm confused about what
the correct behaviour is supposed to be in many of these cases:
contain(double, double, double, double) says "Tests if the interior of
the Shape entirely contains the specified rectangular area". I have
two questions on this. Does "interior of the Shape" mean the set of
points
that are inside the shape as per the "Definition of insideness" in
awt.Shape,
or does it mean everything inside *minus* the boundary? Also, I have
the
same question about the rectangle parameter: does "entirely
contain..."
include the points on the boundary of the rectangle or not?
I'm also confused about contains(Point2D). What should be returned if
the
Point2D is on the boundary? Would this be decided using the
"Definition of
insideness"?
I have similar questions about the intersect methods, but I'm guessing
those
can be extrapolated from any answers I might get about the contains
methods.
Also, contains(double, double) is working properly in the given
reproducer
for 4724556. I'm guessing this is because "contains" used to use
solveCubic
but it's not anymore so it's behaving correctly (at least in this
case). This
bug report is a bit ambiguous since it's also referring to solveCubic
not
finding a root, so I think it should either be closed as fixed or
notabug
or it should be made a duplicate of 4645692.
Thank you,
Denis.
