|
Description
|
A DESCRIPTION OF THE REQUEST :
--------------------
Intro
The Java community would greatly benefit from some critical Graphics2D enhancements. While Java2D has done a great job of modernizing graphics on the Java platform, the Graphics and Graphics2D class has not seen similar work.
This document is scoped to the following shapes:
Shapes: (point)*, line, (triangle)*, rect, (circle)*, oval
Ignoring: arc, rounded rectangle, 3D rect, polygon, polyline, text
* requested additions
--------------------
Critical
(1) The Graphics draw...() methods should be overloaded to accept doubles
Graphics2D added draw(Shape) and fill(Shape) to the Java graphics kit. This is the only way to use doubles in Java graphics routines. The problem: draw/fill(Shape) is *SEVEN* times slower (as tested on Windows XP with 3.6 ghz P4 processor) than the associated draw...() method and that includes using double math to scale the points in software and then cast to int. What this means is that developers must do much more work to gain the sevenfold increase in performance.
Java is increasingly competing with graphics intensive platforms like Flash. It is also gaining increased momentum from the gaming community. Graphics performance may not be important in some Java fields but it is critical to these emerging markets.
--------------------
Less Critical
(2) The Graphics class must add a draw Point / Triangle / Circle method
As Java developers we all get it, use drawLine(x1, y1, x1, y1)... but why?
A drawPoint(double x, double y) method increases code clarity by broadcasting the intent of the statement.
Polygons are critical to 3D graphics work. Arguably the most important polygon, the triangle, is completely unrepresented in the Java library. A drawTriangle(x1, y1, x2, y2, x3, y3) method could actually even be faster. Aside for the performance increase from not having to use a Shape, the Graphics could be able to optimize triangle rendering over a N-Line polygon.
No disrepect to the Oval camp, but how many times are Ovals needs over circles?
The central theme here is that providing logical methods makes our code cleaner. These are 3 methods that I have to fake in my code in every application I write.
--------------------
Recommended
(3) Draw methods should take a shapes *center* coordinates
Aside from rectangles a majority of applications need to reference Shapes
by their center. This is PAINFULLY obvious in Graphics2D where you are scaling, translating and rotating with the AffineTransform. It is then necessary to translate to the center of the shape, transform and then translate back. Settings shapes by their "frame" positions has almost no utility over using their center.
currently: drawOval( (int)(x - (w / 2)), (int)(y - h / 2)), (int)w, (int) h)
requested: drawCenteredCircle(x, y, radius)
The code clarity is phenomenally better. And most importantly the logical notation will cut down on coding errors.
--------------------
Conclusion
Implementing these requests would make the method count inside Graphics and Graphics2D explode and some developers may not like that.
You would have 6 shapes each with one method for:
draw(int), draw(double), drawCentered(double) * 2 for the fill methods
(About 36 methods)
If the method count is a deal breaker at the very least the community should consider a drawShapeName(bool fill, bool cent, double coords...).
This is very ugly but its less ugly then the code copying and lack of code clarity we presently have.
Thanks!
JUSTIFICATION :
The enhancements will increase performance (by almost 7x) and increase code clarity. They will benefit the gaming community. They will also benefit developers in web media fields such as Processing, JavaFX etc as they will allow us to better compete with Flash.
Posted Date : 2008-03-31 08:05:17.0
|
