I think that the Java community should seriously consider updating Graphics2D.
(1)
At the very least every draw() method should be overloaded to accept doubles.
I work almost exclusively with Java graphics and from even simple tests
wrapping the 4 points in a (reused) Rectangle2D to draw vs drawRect() is 8 times slower.
(2)
There should be some serious consideration given to Shapes that are positioned
by their CENTERS! or at least some draw() methods that take centers.
drawCenteredRectangle(double ctrX...)
In 3 years of commercial graphics programming i've almost exclusively had to
position shapes by their center.
(3)
And least importantly, considering the plethora of unneeded methods
in the Java library would it be so much to ask for a drawPoint(double x, double y)
and drawCircle() method?
I get it, we can use drawLine(x, y, x, y) and drawOval(x, y, r, r) but why? I could almost accept this
back in the pre Graphics2D days but now that you can scale the Graphics context
so that a pixel can represent only .1 units how is wrapping a pixel in a Rectangle or Line tolerable?
These things could be fixed by adding about 10* methods
point, line, rect, circle, oval <- 5 doubles, 5 centered 2 fill
(ignoring arc, rounded rectangle, 3d rect, polygon, polyline, text)
Presently, I just work with a Graphics2D wrapper class that provides these 10 or so methods for me.
But seriously, why such laziness in a fundamentally core class?
Edited by: TuringPest on Mar 20, 2008 12:29 AM Forgot about the fill() methods
Post the number here, I've still got 2 votes available to me :-)
But one will go to a RFE I'm planning to file for providing set/getDisabledForeground at Component or JComponent level, presently it's available only for JTextComponent and its subclasses as set/getDisabledTextcolor, which means you can't cleanly and easily set the disabled text color for (say) a JLabel or JButton.
Darryl.Burke wrote:
JSR or RFE? or are they both the same?
I think a JSR is if it is a fair sized change that is fairly well defined (like redoing the way dates work, or adding scripting capabilities to the language), while RFEs are for small things that Sun will ignore for ever more.
Plus JSRs are sexy. And having a "JSR xyz expert group" would look good on a C.V.
does everyone just get 2 or do you have to earn them somehow?*
Everyone has three votes. All of mine are used, all on things with Sun engineers saying "we will have it for version 1.4, no 1.5 1.6 really, 1.6. OK maybe 1.7".
More Editing If you really want it your best option would be to include a patch (now the source is downloadable) with your RFE/JSR and look up what you need to do to get stuff submitted to the source.
Darryl.Burke wrote:
But one will go to a RFE I'm planning to file for providing set/getDisabledForeground at Component or JComponent level, presently it's available only for JTextComponent and its subclasses as set/getDisabledTextcolor, which means you can't cleanly and easily set the disabled text color for (say) a JLabel or JButton.
I filed one last year that was somewhat similar to this, with no response.
JComponents have get/setEnabled, but JTextComponents go a step further by having get/setEditable.
My issue was trying to have a getter/setter for a read-only attribute for ALL JComponents. Basically, the components would appear normal (undimmed) but can't be modified. Since JTextField supports this, why not all of them? Unfortunately, get/setEditable has a different meaning on JTextField than it does on JComboBox (way to go guys), so a new name would have to be chosen (get/setReadOnly ?).
a JSR is sexy, lol. i will consider creating one but it seems like it will take some work.
ill need to build a coalition to back me!
i just submitted the RFE.
when I hit "submit" they didnt give me a link to my RFE so I guess im waiting for
an email from them. I will post it when I get it.
the text of my RFE submission is below.
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.
With a one-line solution provided, the bug is yet to be registered. If that's the treatment a report of an identified bug gets, there's not really much hope of an RFE making it, is there? <cynical/>
Kel has a point, read-only is not the same as disabled -- apart from the foreground color, text can be selected and copied from a read-only item, but not from a disabled one.
Darryl
edit Since links now work, and nobody had replied to this particular post..
OT, but im shocked that the #9 RFE is operator overloading!
in fact, im not very impressed by any of the top #25 except for the addition of Ogg Vorbis.
(i wish they would add Theora to that as well!)
This topic has
17
replies
on
2
pages.
1
|
2
|
Next »
Email this Topic
Edit this Topic
