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

[Jim Graham]

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:

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

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

			...jim

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.