(patch) java.awt.geom - implementations

[Sven de Marothy]

Hello classpathers!

Here's a patch which implements some missing stuff in java.awt.geom.*

The patch includes implementations of:
contains() and intersects() for QuadCurve2D, CubicCurve2D as well
as an implementation of GeneralPath, with documentation.

It appears the current files were not formatted with Tom's GNU.xml
jalopy file, therefore the patch is rather big (100k), so I put it
here:
http://www.qc.physto.se/~sven/Geom/
I made a nice pedagogical image file for the GeneralPath
documentation, too. That goes in java/awt/geom/doc-files/

Ok, the red-tape. My FSF assignment papers are in the mail, so 
they're not registered yet. But I think you can still commit this,
right? 

If anyone's interested the technical details are coming up now:

It's an implementation of the line-crossings algorithm. 
Sun uses the same, apparently, but they did not mind the
special-case of vertice intersections, which IMHO is a pretty bad
bug. (they count as a single intersection of the ray, i.e. if the
vertice is at (X,Y) points with x < X, y=Y may be counted as inside.)

There is however one bug in the code: degenerate roots of cubics
are returned as a single root by the cubic-solver. Hence, a curve
with a loop (think figure-8) will erroneously return true. This is
rarer, and most likely present in Sun (haven't tested for it though).
Changing solveCubic() to report degenerates seperately would fix
this, but also be inconsistent with Sun. Adding a check for this
special-case seems to me a bit expensive though. 

The GeneralCurve.contains() method will always return false in the
case of a rectangle which intersects the path, even if the path is
between two segments which are 'inside' in the NON_ZERO winding rule.
Evaluating the 'insideness' at each intersection would be too expensive.
Sun does this too, but at least my docs reflect 
exactly when this occurs.

I did a little optimizing and benchmarking. It's a tad (~15%)
slower for GeneralPath and QuadCurve2D, except for point-testing, 
which is faster. CubicCurve2D seems signicantly faster though.

Ok. I guess I should write some Mauve-tests for this?

/Sven