The reason there is no method for drawing them is that they don't
describe any geometry to draw. Also, the question of what exactly the
user wants us to draw gets a little fuzzy as we introduce antialiasing,
scaling, and printing on high resolution printers to the mix.
If this were a pixel-based API then "drawing a point" would mean "turn
on the pixel at x,y coordinate.
But this is a scalable, transformable vector-based geometry API.
drawPoint primitives don't tend to exist in such APIs. I haven't done
a formal search, but a primary example is PostScript where you need at
least a moveto and also a following lineto or curveto to have anything
appear. A single moveto (which would be what a Point by itself
represents) would render nothing.
So, what do you want us to do "on or near the coordinate x,y"? Draw a
box? Draw a circle? When you scale it up or print it, the difference
between the two will become more evident.
If you're transform represents a 1:1 coordinate to pixel mapping with
only an integer translate, then fillRect(x, y, 1, 1) will best
approximate what most people expect from a drawPoint(x,y) API in a
pixel-oriented coordinate system, and may even visually approximate
what many people look for when printing such a graphic or zooming in on
it, except that it isn't centered around the coordinate.
If you'd rather they were round when you zoomed in or printed, then
drawOval() would look better, but involves more processing for the
simple case of rendering on screen at a 1:1 scale.
If keeping the box or oval centered around the coordinate is desirable
then creating a shape with origin x-0.5, y-0.5 and dimensions of 1x1
would help that, but that will also involve more processing in the
simple 1:1 unzoomed screen rendering case.
Using draw(Shape) or drawLine() is frought with problems in that the
outcome will depend on the line width and the line styles and
variations in those attributes could turn that rendering into just
about anything, especially when zoomed up to where you can tell the
difference between the various line caps. CAP_BUTT will render nothing
for a zero length line, CAP_SQUARE will render a box whose orientation
is undefined, and CAP_ROUND will render a circle.
Given all of these considerations, it seems easier to just let the
developer use the rendering that will describe what they want to
appear. Of the choices, fillRect() is the most expedient for screen
rendering and has some a specific rendering definition that is easy to
work with, though not centered around the coordinate if that is
important to you...
...jim
--On Thursday, September 9, 2004 2:49 PM -0400 Gregory Pierce
<[EMAIL PROTECTED]> wrote:
While running some tests on a program that generates a dataset of
(x,y) pairs I decided that I would render them so I could see how the
data was distributed visually. Almost immediately I ran across an
interesting limitation:
"Except for Point2D and Dimension2D, each of the geometry classes
(geometries) implements the Shape interface, which provides a common
set of methods for describing and inspecting two-dimensional geometric
objects."
No biggie, I thought, I guess they aren't really 'shapes' so I'll just
draw them using Graphics2D. Hmmm... wait there is no method in
Graphics2D to draw them either. Ugh, that means I have to create one
pixel sized rectangles to draw points?
=====================================================================
====== 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".