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

[Denis Lila]

Ah, I'm sorry. I forgot to CC the list.

----- Forwarded Message -----
From: "Denis Lila" <dlila at redhat.com>
To: "Jim Graham" <james.graham at oracle.com>
Sent: Tuesday, February 1, 2011 6:04:09 PM
Subject: Re: [OpenJDK 2D-Dev] CubicCurve2D.solveCubic and containment/intersection bugs.

Hi Jim.

The webrev for the performance improvement is here:
http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/

I have changed a few things since the last time you looked at it.
The largest change is in Curve.java in breakPtsAtTs. I changed its return
from an Iterator<float[]> to an Iterator<Integer>, which allowed me to
change middle in Stroker from a float[2][8] to a float[16]. I also
eliminated the call to updateTs and the bouncing back and forth of the
subdivided curves in breakPtsAtTs.

The other major change is the implementation of the cubic solver in
Helpers.java (which is used in Dasher.LengthIterator). It's almost
identical to what I just commited to awt.geom.CubicCurve2D. I'm not
using the version in awt.geom because I want to avoid the array creations
but most importantly because we don't need anything even close to the
accuracy that CubicCurve2D provides. In fact, most of the time*,
LengthIterator's arguments to solveCubic are such that there is only
one solution, so I considered removing the 2 root case altogether just
to skip the within(D, 0, 1e-8) call (I haven't done this yet because
I wanted to check with you first).

* "most of the time" is a bit of an understatement. I've tested this with
tens of thousands of Dasher.curveTo calls, and I've never seen a case
where there is more than one root.

Regards,
Denis.

----- Original Message -----
> Actually, if you just want to type up a quick "description" I'll file
> the bug...
> 
> ...jim
> 
> On 1/27/2011 2:26 PM, Jim Graham wrote:
> > On 1/27/2011 2:03 PM, Denis Lila wrote:
> >> Well, it is pushed. Now all that's left on my end is the
> >> performance
> >> improvement for pisces (dashing in particular). Could you please
> >> file
> >> a performance regression bug for it?
> >
> > What are we regressing from? Is it slower than the previous OpenJDK
> > rasterizer?