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

[Jim Graham]

Hi Denis,

There is another bug out there where I've indicated the need to beef up 
our documentation of the intersection methods (see 7003516).

The Shape class comments give some helpful information that describes 
our boundary conditions.  We basically use half open intervals where the 
upper/left boundaries are contained in the shape and the lower/right 
boundaries are not.  The description is describing more specifically 
"which pixels are filled", but it is related to the philosophy behind 
the intersection methods as well (and we need to call that out).  So, 
Shape.contains(point) follows those guidelines.

For the rect methods, I think we should also clarify that:

	intersects(rect)

means there is some point that is contained in both the shape and also 
the rect (as per the Shape class comment), and:

	contains(rect)

means that for any point that is contained in the rect, it is also 
contained in the Shape - again per the Shape class comment.

I agree with your comment about 4724556 - I just closed it as a dup of 
4645692.

Also, note that Path2D now uses a very fast general intersection 
facility in the sun.awt.geom package that is based on the above rules. 
The containment methods of all of the various shapes could be switched 
over to this mechanism except that the may have faster ways of finding 
the answer in some cases.  Certainly Rectangle2D can figure out the 
answer faster on its own, but I'm not sure if CubicCurve2D or 
QuadCurve2D are any faster than simply utilizing those methods, though...

			...jim

On 1/11/2011 1:06 PM, Denis Lila wrote:
> 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.