Note that "Area" is specifically targeted to processing areas, not
outlines. While it does express its answer in the form of an outline,
on the other hand the information it is processing, operating on, and
representing internally is areas, not outlines. It's output is intended
only for filling, not for stroking. You can stroke its output because
the graphics system allows you to stroke any path, but the Area class
wasn't concerned at all about stroking issues (such as path direction)
during its internal operations.
If you are simply trying to simplify the polygon to throw out
unnecessary segments to simplify rendering then the Area class is not
designed or optimized to address your needs. Additionally, it is doing
way more work than your application needs and writing your own
implementation may perform better.
Also, Area will perform optimizations that you don't want such as
removing an interior segment that does not contribute to the boundary
between interior and exterior. Such segments are superfluous for
filling, but might be visible when stroking. The Area class won't care
and will just delete them all the same because it only cares about areas
internally.
Another issue to consider is that if you have arrows or other periodic
decorations then removing segments will mean that those decorations will
shift their locations. The length of the omitted path must be
considered while computing where the decorations are placed, but if you
pre-edit the path to remove them then those lengths cannot be computed.
Out of curiosity, are you trying to clip these paths to avoid having to
process decorations on parts of the path that are far outside of the
clip? We've recently discussed that performance issue internally in the
Graphics-Rasterizer project and noted that it is an opportunity for
future performance work...
...jim
On 10/7/15 12:37 AM, Hruda, Steve wrote:
Hi Jim,
we are using the Area to clip/intersect geometries like a polygon. Such a
polygon has a digitizing direction and this direction has an effect on the
point order.
If we visualize a clipped polygon in our map, than we have the problem that
complex line styles like a placed graphic along a line e.g. an arrow, shows in
the wrong direction.
Thanks for the explanation Jim, I will consider the point-order manipulation in
our application.
Regards,
Steve
Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H.
Vertretungsberechtigte Geschäftsführer: Maximilian Weber
Sitz der Gesellschaft: Margaretenstraße 70/I/1, 1050 Wien, Österreich, Tel. +43
(1) 9610567-0
Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b
Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer:
264/4807
This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H.
Authorised Managing Directors: Maximilian Weber
Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien,
Austria, Tel. +43 (1) 9610567-0
The company is recorded at the commercial court of Vienna under the company
register number FN 116859 b
VAT-ID: ATU15138401, Austrian Tax ID: 264/4807
Diese E-Mail (mit zugehörigen Dateien) enthält möglicherweise Informationen,
die vertraulich sind, dem Urheberrecht unterliegen oder ein Geschäftsgeheimnis
darstellen. Falls Sie diese Nachricht irrtümlicherweise erhalten haben,
benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und
löschen Sie bitte diese E-Mail und Ihre Antwort darauf. Sämtliche aufgeführten
Ansichten oder Meinungen sind ausschließlich diejenigen des Autors und
entsprechen nicht notwendigerweise denen des Unternehmens Intergraph.
This E-Mail (and any attachments) may be confidential and protected by legal
privilege. If you are not the intended recipient please notify us immediately
by replying to the sender and delete this E-Mail and your reply from your
system. All the views and opinions published here are solely based on the
author's own opinion and should not be considered necessarily as reflecting the
opinion of Intergraph.
-----Original Message-----
From: Jim Graham [mailto:james.gra...@oracle.com]
Sent: Tuesday, October 6, 2015 8:38 PM
To: Hruda, Steve <steve.hr...@hexagongeospatial.com>
Cc: Sergey Bylokhov <sergey.bylok...@oracle.com>; 2d-dev
<2d-dev@openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> Question: Area changes order of points
Hi Steve,
Area simplifies the shape into a normalized version that defines the same
interior area. It does not care what the original ordering of the points was
as it internalizes the shape, all it cares about is which areas are
geometrically inside vs. outside and it creates a path according to its own
internal policies that defines the same inside/outside boundaries.
There is no "trick" to customizing this behavior and I'm not entirely sure why
the point ordering would matter when you are performing CAG (Constructive Area Geometry)
operations - only interiors and exteriors should matter.
...jim
On 10/5/15 8:19 AM, Sergey Bylokhov wrote:
Hello,
I think this question is related to java2d, correct alias cc.
On 24.09.15 12:53, Hruda, Steve wrote:
I use the java.awt.geom.Area class to clip a shape. Today I noticed
that new Area(Shape) changes the orientation of the shape, so that I
get the points of the Area counter-clockwise in every case.
The following test shows you my problem.
https://drive.google.com/file/d/0B7P_rknS1TWxVGJ6a3hBaElBTk0/view?usp
=sharing
Is this a bug or do I something wrong?
Is there a trick to get the points in the correct order?
