Olivier Lefevre wrote:
GeneralPath in Java 2 [...] can handle polygons and much more
API-wise yes but is there a performance angle or is Polygon
really redundant now?
It depends on how you would use Polygon as to whether or not there would
be a performance penalty or not.
First, there are 2 sides to the story - how fast it is for your program
to maintain the Polygon[2D] versus maintaining a Path2D - and how fast
can we render each Shape type.
With respect to setting up the polygon, the Polygon class has this nice
exposed data structure that might let some applications just copy some
new data in as fast as an arraycopy and that could be a great
performance boon for those specific operations. But, there is some pain
associated with exposed data structures insofar as the object cannot
really trust any cached information about its internal data whereas an
object with hidden structures can. In the end, most design books would
recommend that objects are better off hiding their internal fields
behind fast accessors, both for maintaining correctness, and for opening
themselves up to possible optimizations for trusted code. So, this
particular advantage of Polygon is dubious at best.
In contrast, Path2D and GeneralPath hide their data and provide many
methods for manipulating the data. If those methods map onto your needs
well then you can usually set one up optimally. As with any API, there
may be some applications that might find the specific methods they
provide insufficient and working around with them might not be as
optimal. YMMV.
Space-wise the Path2D objects boil down mostly into a pointer to an
array of floats or doubles for storing coordinates, and a pointer to an
array of bytes for storing path types. A Polygon2D.Float would take 8
bytes per vertex (2xfloat) vs. 9 bytes per vertex for a Path2D.Float.
The Double versions would take 16 vs. 17 bytes per vertex. The added
space is not huge, especially for double data.
In the end, though, with today's machines being as fast as they are,
unless you are constantly updating the geometry in the polygon in an
inner rendering loop there shouldn't be any performance issues there.
With respect to rendering, if all things were equal - if all shapes were
treated as generic shapes by the renderer - then there would be little
performance difference between the two. But, not all things are equal.
Some pipelines can take a Polygon directly and render it, others treat
all shapes by getting their PathIterator. We also have some pipes
internally that copy all shapes into a Path2D.Float and then render that
directly (the native code digs in and grabs the necessary data
directly). So, sometimes a Polygon object might be faster than an
equivalently defined Path2D, in other cases it might be slower. And, it
may depend on (and vary by) whether you render with a solid color vs.
alpha, or with a more complex Paint, or with a wide stroke, etc.
But, even if we created Polygon2D with Float and Double variants, there
would still be some work required to do anything more specific than to
just treat it like an everyday shape and ask for its PathIterator.
There would have to be a trade off between the pipelines looking for
Polygon2D.Float and Polygon2D.Double and writing new code to render them
directly, added to the code that already might special case the Path2D
equivalents, and we'd end up with a lot more code to enable the
Polygon2D hierarchy - or we might avoid the added code and just treat
them as any generic Shape - in which case they would definitely not be
any more advantageous than using a Path2D. There wouldn't be much
performance difference between the two if they boiled down to iterating
their PathIterators.
It would be best to measure your particular use case to find out, but
I'm not sure one use case would constitute grounds for adding even more
Shape variants to the base APIs. If there is significant overhead you
find in setting up a Path2D, but the rendering isn't an issue, then you
could always create your own Polygon2D with maybe an hours work (copy
the Polygon code and just upgrade the storage). Note that in 1.6 there
are even helper methods in Path2D for computing the answers for the
intersects() and contains() methods which are the more difficult parts
of a Shape API.
> And if so why not deprecate it since
you are concerned about API bloat?
With regards to deprecation - deprecation was common back in the early
days of 1.1 and even 1.2 when it was new - all APIs that weren't the
"latest greatest" were deprecated, but it got to a point where
deprecation didn't really mean much any more. The general philosophy
these days is to deprecate something only if there are specific problems
associated with its use that cannot be worked around. A Polygon is
still perfectly useful for the original purpose for which it was
designed, and so not worthy of deprecation. But, the fact that Polygon
is not worth deprecating doesn't necessarily mean that it is worth
expanding upon it with Polygon2D APIs...
...jim
===========================================================================
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".
