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".
