I wanted to follow up this suggestion with a warning.
The Area object is not a generalized Shape. It has some very specific
properties which make it inappropriate for some Shapes. Most of these
should be documented in the latest javadoc for the Area class.
1. Area cannot represent shapes which enclose no space, such as a Line.
Line2D is a Shape since it has a path and can be stroked, but it
cannot be filled. An Area constructed from a Line2D is an empty Area
containing no geometry since an Area only represents enclosed regions of
space.
2. Area will implicitly close a Shape upon construction. If you define
an open triangle consisting of 2 lines and you draw that Shape then only
2 lines will be drawn. If you construct an Area from that Shape and
then draw the Area, 3 lines will get drawn to represent the closed triangle.
3. Area performs a *lot* of calculations on a Shape when you construct
it. The purpose of these calculations is to internalize a
representation of the regions of space that are enclosed to make the CAG
operations (union, intersect, subtract, xor) easy to implement. Those
calculations are pretty fast if your goal is to perform CAG with the
Shape, but they are unnecessary if you are not using it to perform any
CAG. The CAG operations go much faster because of these
precalculations, but if your only goal is to use Area to make a Shape
relocatable then the Area class (and its corresponding caveats and
precalculations) is overkill.
4. When you use the Area.transform(AT) method, the precalculations that
were done when the Area was constructed must be reexecuted and that
takes additional time as well.
As a result, I wouldn't use the Area class unless you are planning to
perform CAG operations on the Shapes.
However, the GeneralPath class (and now Path2D in JDK 6) offers very
similar capabilities. There is a GeneralPath.transform(AT) method just
as on the Area class. The even better news is that GeneralPath is
simply a repository of geometry, unlike Area, so it is very fast to
create one from an arbitrary Shape and it is also fast to transform it.
In the end, though, if you are having to implement any kind of mechanism
to manage your Shape objects, I would put translation (and other
transformation information) into that architecture and go for a full
Model/View approach rather than look to transform the Shapes themselves...
...jim
[EMAIL PROTECTED] wrote:
Hi swv,
I'm definitely not comfortable with my own Java2D capabilities but recently
I've been working with the Area class alot and I think you should take alook at
it. It is a mutable shape implementation as far as I know - take alook at
Area.transform(AffineTransform at). With this you wouldn't have to translate
your Graphics object at all, and your areas will still be where you left them
the next time paint is called. Also, Area can take any Shape in its
constructor and it will try to construct a suitable Area interpretation of the
given shape. Just remember to translate the new Area as necessary. I hope this
may be of some assistance.
Regards,
Pierre
[Message sent by forum member 'irond13' (irond13)]
http://forums.java.net/jive/thread.jspa?messageID=228441
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
