[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

Jim Graham james.graham at oracle.com
Tue Dec 14 01:54:55 UTC 2010

Hi Denis,

Those sound like just the kind of problems I believed existed in the 
CC2D algorithm.

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:

(etc.  Those were just the bugs I found on the first 2 pages of a bug 
database search)

Double (triple, etc.) credit - woohoo!  ;-)


On 12/13/2010 2:30 PM, Denis Lila wrote:
>> Very nice!  How does it compare to CubicCurve.solveCubic() (which I
>> know
>> has issues with the 2 root case, but I got it from a "reliable source"
>> -
>> some textbook on Numerical Recipes)?
> I wrote a tests that generated 2559960 polynomials, and in 2493075 of
> those, the computed roots were identical to within 1e-9. They were
> different in the remaining 66885 cases, so that's 97.4% agreement.
> I've looked through some of the differences, and in every case the
> function from graphics gems is better in one of two ways:
> 1. the gg version will report more roots than the cc2d version, in
> which case the polynomial has a double root and the cc2d version
> completely misses it (example poly: a=19.000000, b=-20.000000,
> c=-17.000000, d=18.000000, where cc2d misses the root at 1).
> 2. the gg version will report fewer roots than the cc2d version, in
> which case there was a 0 root and the cc2d version incorrectly split
> it into -1e-163 and 1e-163.
> So, the graphics gems version seems to be much more stable. It
> does have a problem where it can return NaN sometimes, because it
> assumes that the polynomial is not a quadratic one, but that can
> easily be fixed.
> So, should I put this new cubic root finder in CubicCurve.solveCubic
> and use that in pisces?
> Regards,
> Denis.

More information about the 2d-dev mailing list