Bug ID: JDK-4632108 Area.transform and Area.createTransformedArea should maintain double precision

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b45Fixed

please refer to bugID 4558900. I added additional info in this RFE to go along with info that is contained there. Also I am filing this as a new RFE as there is an escalation attached to the other bug. This issue was deemed to be an RFE rather than a bug.

Attached also is a piece of code to demonstrate how AffineTransform is
altering the shape after transformation. The coordinates used are test_corrd.txt, and the results from the run are in results.txt. As you would
notice, the transformed shape is returning a self-intersecting polygon
where as the original shape is not a self-intersecting polygon

It was suggested customer create an extended class of the Area, for example,
"AreaWithOffset", in which you store a Area together with an offset
and then override the Area method, and only when the coordinates are
needed you can add the offset to them.

customer feels;
This approach seems to work well for this application. However, I still feel
this just a work-around to overcome a java 2D limitation. This approach
breaks whenever coordinates deviate from offsets by more than what the
floating point range can allow for. This translates to 8.388607 degrees
( (2^23) -1, allowing for 6 decimal places) for our data to ascertain
accuracy. Many a time, some of the polygons that we deal with cover more
range than this. Such situations will give rise to inaccuracies and invalid
shapes as a result of floating point truncation. A double precision
capability for this kind of scenario will solve our problems and make java
2D technology stand out against competing technologies. I am not sure what
are all the issues involved with this, but I sincerely hope Sun ought to
provide this capability in some fashion or other.

EVALUATION There is an existing rfe, 4172661 : GeneralPath needs double version, that covers the GeneralPath request. ###@###.### 2002-02-01 First, Area objects already use double precision coordinates to store their information. They do process their input paths, though, to convert them to a canonical representation with no self-intersecting paths. So an Area object should not be used as a "loss-less" storage format as it may represent the geometry differently than the original. On the other hand, this geometry does not appear to be self-intersecting since the first Area object returns the geometry unaltered. The GeneralPath in this case, is only used to store the translated coordinates temporarily between calling makeShape and creating an Area object from it. Since those translated coordinates are all small, the fact that the GeneralPath uses floating point precision does not affect its accuracy in this case. The precision seems to be lost when the geometry is transformed. It looks like the Area object uses AffineTransform.createTransformedShape() to transform the geometry and that latter method uses a GeneralPath to store the transformed geometry. This points out two deficiencies in the core classes: - Area should try to do a more direct transformation of the geometry rather than use the utility method on AffineTransform to transform the geometry - AffineTransform is inherently truncating coordinates to single precision when it transforms them. The first can be fixed by avoiding the utility method and re-factoring some methods that already exist in the Area class. The second can only be fixed if AffineTransform has a decent class for storing the transformed geometry at greater than float precision. Since that depends on providing a double-precision alternative for GeneralPath, I will create a new bug with a dependency on 4172661 that asks for better precision in AffineTransform. ###@###.### 2005-07-15 00:42:31 GMT Both Area.transform and Area.createTransformedArea were easy to fix with just a few lines of code changes. Committing this bug to Mustang. ###@###.### 2005-07-15 23:06:55 GMT

15-07-2005

Relates :	JDK-4172661 - GeneralPath needs double version
Relates :	JDK-6385010 - REGRESSION: java.lang.InternalError: backstepping from (Transforming Area)