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

[Jim Graham]

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.