This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
On Mac OS X (Tiger with JDK 1.5) the fonts in the editor of NB 6.0 beta are antialiased though the setting of the checkbox of the Advanced Options -> Editor dialog is switched off. I would prefer non antialised fints since I consider them to be much sharper and better readable. The current fonts in the editor are way to blurry to use NB 6 beta as a replacement for NB 5.5.1.
Seems to be always antialiased on my ubuntu/gnome box too. I tried with JDK6, not sure if there is any difference on JDK5.
On 1.6 the antialiasing and the corresponding AA rendering hints are determined from the JVM only (recommendation from Swing team - implemented as issue 86864) so the checkbox should always correspond to the OS AA settings. We should probably gray the button. On 1.5 the AA checkbox setting should be reflected so I'm wondering whether the problem isn't in that we decide upon awt.font.desktophints property that might be initiated on Mac even in 1.5: BaseOptions.java: Map defaultHints = (Map)(Toolkit.getDefaultToolkit().getDesktopProperty( "awt.font.desktophints")); //NOI18N if ( defaultHints != null ) { // OK We're at 1.6 or higher
@mmetelka: I think this property is not set. I am using 5.5.1 and would like to use 6.0 on Mac OS X. With 5.5.1 fonts are sharp with 6.0 blurry. Same JDK (with Mac OS X Tiger one has no choice really) same user. I googled a bit around and found hints on apple's developer site: http://developer.apple.com/documentation/Java/Conceptual/JavaPropVMInfoRef/Articles/JavaSystemProperties.html I've tried to set apple.awt.textantialiasing to off by twiddling the command line switches in the netbeans.conf file. It kind of worked. Until I switched to the Welcome Screen or reopened a file. After any of these actions the text changed from sharp to blurry again. Could it be that you change these properties under certain circumstances in Netbeans?
Oops the issue number had typo - it should be issue 85864. Sorry. I guess the easiest will be to add a logging into the BaseOptions for antialiasing property and rendering hints computation and we will see.
I've just installed NB 6.0 beta on my linux box and I see the same behaviour. On linux the editor text is also antialiased no matter what I click in the checkbox in advanced options. The only thing that changes is the antialiasing of the line numbers. On linux this is not as much a problem as on OS X since the text is not antialiased that much as on the Mac and therefor doesn't look as blurry. But still worse than in NB 5.5.1. On linux I use JDK 1.5.0_09 of SUN. BTW: I've verified by using the newest CVS version on Mac OS X that the defaultHints-check in BaseOption.java that mmtelka mentioned above correctly identifies the JDK as being JDK 1.5. So this cannot be the reason for this behaviour.
Still unresolved in Beta 2. I've experimented with the cvs version and it seems to be that org.netbeans.swing.plaf.util.UIUtils is causing the problem. The method "configureRenderingHints" sets the RenderingHints of the graphics context to ANTIALIAS. This class has been changed dramatically in 2007 (http://deadlock.netbeans.org/fisheye/browse/netbeans/core/swing/plaf/src/org/netbeans/swing/plaf/util/UIUtils.java#bMAIN) so this would explain why this issue is not also an issue fopr NB 5.5.1. The funny thing is that the comment for this class states that the class has s.th. to do with Win XP (XP color scheme installer) - no other comment is given. Nevertheless UIUtils this method is called from Aqua-L&F related classes (and I think GTK-L&F as well). According to Fisheye most of the class is edited by Tim Boudreau. So maybe s.o. from the NB team could assign this bug to him?
Tim, have you got any ideas please?
On Mac OS w/ Aqua L&F on JDK 5, AFAIK Apple uses their own native rendering pipeline for text rendering for standard Swing components - I am not sure that it is possible to turn off antialiasing for text controls on Mac OS. Possibly this will work if you run with Metal L&F instead, not sure. Not sure what's going on with Linux. On JDK 6, the code that sets antialiasing should look up a Map containing the default desktop rendering hints (i.e. possibly subpixel antialiasing hints) as a desktop property, and if it finds it it should use them if the checkbox is checked, and ignore them if it is not; if the map is null (i.e. JDK 5 or such), then a Map of rendering hints should be auto-generated with plain text antialiasing settings if the checkbox is checked, and unset if not. It could be that the Graphics object being used is inheriting the rendering hints from some other component that rendered, and added the hints to the Graphics object before passing it to the text control's paint method. Probably the easiest way to track this down would be to write a Graphics2D implementation that wraps the real Graphics object and logs calls that set rendering hints with a stack trace, and find the culprit that way (if you want a handy starting point, there are a couple such wrapper implementations of Graphics2D in the source for http://imagine.dev.java.net that could be reused for this).
Apropos of this, a good discussion of Apple's rendering pipeline here: http://weblogs.java.net/blog/javaben/archive/2007/10/java_on_leopard.html
*** Issue 121629 has been marked as a duplicate of this issue. ***
So since this bug occurs on Solaris (see duplicate issue 121629 that explicitly states Solaris), linux and Mac but _not_ on Windows (I have just checked the release candidate on Windows) this most probably is due to the look and feel implementations. I therefore changed the component to UI and the subcomponent to Painting & Printing. I consider this to be a showstopper for NB 6 on any platform other than Windows. I therefore also changed the priority.
Well, the UI component does not have Painting & Printing subcomponent (it's editor's subcomponent). When you reassign issues please choose 'Reassign issue to owner of selected subcomponent' before submitting the form. I actually think this really needs to be investigated in the editor, so reassigning back. It's unlikely to get fixed in nb6 for two reasons - first nb6 is in high resistance, but more importantly we don't have the fix. I'm sorry.
This is not a P2 bug according bug priority guidelines. http://qa.netbeans.org/bugzilla/bug_priority_guidelines.html
*** Issue 133261 has been marked as a duplicate of this issue. ***
This is all different in Nb 6.5. First, there is no checkbox in Tools-Options for controlling text AA. The IDE simply does whatever the JVM it is running on does. That is, with JDK6 running on a system where JVM can detect system specific text AA settings (eg. Win XP/Vista, GTK based window manager on linux, ...), these settings are used. With JDK5 or when running on a system where text AA settings can't be detected no text AA is used. The exception to this is Mac OS X where we force text AA even when JVM can't detect the OS AA settings. There is also '-J-Dswing.aatext=<true|false>' property, which can be used to control text AA in the rare cases when the system default are not acceptable. Also, please note that there are different algorithms for text AA available in JDK6, but they can only be used on systems where JVM can detect system wide text AA settings. On Mac or other systems when forced by swing.aatext=true the default AA algorithm (eg RenderingHints.VALUE_TEXT_ANTIALIASING_ON) is used. See also issue #137845.