[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] java.awt.geom.Area produces extraneous short segments
From:       james.graham () oracle ! com (Jim Graham)
Date:       2012-03-08 21:10:20
Message-ID: 4F59203C.3050803 () oracle ! com
[Download RAW message or body]

Hi Alex,

Downloading the Open JDK and looking at the sun.awt.geom package is a 
good way to start.  That package is 90+% devoted to implementing Area 
(with a couple of tools used by other java.awt.geom classes)...

			...jim

On 3/7/2012 4:25 AM, Alex Lam S.L. wrote:
> Hi there,
>
> I am very interested in this Area, as one of our application depends
> on it to perform many geometric computations.
>
> Although I have not read any source code under sun.awt.geom.* yet, as
> I cannot gain access to it from the regular JDK and NetBeans'
> ctrl+click - I guess I can just check it out from the OpenJDK
> respository?
>
> Your proposal seems to tackle the fundamental problems rather than
> patching the symptoms, which is promising. For instance, if I feed an
> Area's PathIterator directly back to a new Area (thus calling
> pathToCurves() on it) it will produce many tiny Curves, which is one
> of the many causes for my problems later on.
>
> If you can give me some pointers as to where to start looking, I would
> be happy to get going.
>
>
> Alex.
>
>
>
> On Tue, Mar 6, 2012 at 11:53 PM, Jim Graham<james.graham at oracle.com>  wrote:
>> Hi Alex,
>>
>> Are you interested in working on Area?  I'd love to see some improvements
>> made to this, but it can get to be a bit like whack-a-bug at times with a
>> fix here causing problems over there.  Some areas where it could use some
>> "love" would be:
>>
>> - trying to keep original vertex values around so that when a curve is
>> sliced up and then meets copies of itself, they can be mended back into
>> larger curves to reduce the amount of "geometry dust" created.  This is a
>> subtle improvement, but helps with a lot of repeated operations. Basically,
>> when we come up with a new set of curves for the result of an operation we
>> may subdivide a curve, but a subsequent Area op might require us to compare
>> that new piece of the curve against a piece of another curve that we already
>> found the intersection point for.  Due to slight rounding errors when
>> subdividing both of the original curves the math of comparing them might
>> find a slightly different intersection point causing us to subdivide them
>> further - even when those curves were not in contention during the
>> subsequent operation.  My thought was that if the original vertices were
>> kept around and all comparisons done on the original curves (plus start and
>> end t parameters) then the answers would remain stable over repeated
>> operations - we'd then do the actual subdivision only when force to iterate
>> the answer in a PathIterator.
>>
>> - caching results of finding the intersection between pairs of curves
>>
>> - faster convergence on intersection points (or non-intersection) of very
>> close, but not quite parallel, curves due to better curve comparison math
>> and algorithms
>>
>> - finally tuning isClose() as a last resort if the above don't help with
>> many of the current problems, but I'm hoping that they will help enough that
>> isClose() will no longer be seen as the culprit and can remain at a high
>> precision
>>
>> My original test case for working on this code was a basher that combined
>> dozens or hundreds of displaced circles orbiting a central point (sort of
>> like spirograph except it was many circles rather than a spiral) and you
>> could see the performance bog down as the number of circles increased.  Test
>> cases with a number of "circle minus arc-of-same-circle" tests would also be
>> useful since that is a common operation that people try and eventually give
>> up on because we don't always notice that the curves are essentially the
>> same with IEEE rounding errors...
>>
>>                         ...jim
>>
>>
>>
>> On 3/5/2012 6:06 AM, Alex Lam S.L. wrote:
>>>
>>> I have been using java.awt.geom.Area extensively in my project and
>>> have been hit hard by the problems due to rounding:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818309
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724141
>>>
>>> There may be a few other reported issues as well which I missed.
>>>
>>> I have since found a workaround which at least works well for me - by
>>> modifying AreaIterator (see attached). Obvious place for improvement
>>> would be to isClose(), as it is hard-coded to handle a fixed precision
>>> for now.
>>>
>>>
>>> Regards,
>>> Alex.

[prev in list] [next in list] [prev in thread] [next in thread]