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<[email protected]> 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.
