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.
dev build 200806201204 build 1.6.0_10-beta-b25 I upgraded from a dev build a week ago to this build. All of a sudden the fonts look a lot harder to read. It looks as if something changed in terms of the anti-alias handling (I didn't change JDK version).
Created attachment 63183 [details] screenshot (the top of the text file is especially bad!)
Created attachment 63184 [details] Screenshot from older release, this looks good!
Created attachment 63185 [details] Older screenshot, this looks good!
Please delete screenshot2.png uploaded on 19:34:00. Then please compare screenshot.png to screenshot2.png as they show exactly what I'm talking about.
Reassigning to "editor".
The editor on the first screenshot does not seem to be using antialiasing. There have been changes in the settings infrastructure (see issue #90403). Could you please retry this with a fresh userdir? If the problem goes away, please zip-up and attach your original userdir (ie. the contents under 'config/Editors' should be enough). Thanks
The problem occurs even with a fresh userdir. It is especially pronounced in the "Norway Today" color profile. BTW: Is anti-aliasing configurable from inside Netbeans? If so, where?
> BTW: Is anti-aliasing configurable from inside Netbeans? If so, where? No, it is not, but should become part of a coloring profile.
What OS are you using? It seems to be working fine on my Ubuntu. That is anti-alias=off with JDK5 and anti-alias=on with JDK6. Product Version: NetBeans IDE Dev (Build 080626) Java: 1.6.0_10-ea; Java HotSpot(TM) Client VM 11.0-b11 System: Linux version 2.6.22-15-generic running on i386; UTF-8; en_US (nb) Userdir: /home/vita/devel/netbeans/main/nbbuild/testuserdir
I am running under Windows Vista x64. I would appreciate it if you could increase the priority of this bug because it prevents me from using newer dev builds. Normally I wouldn't mind the anti-aliasing setting too much but this particular bug causes the fonts to become difficult to read (some lines render as less than one pixel wide) so I can't use it for more than a few minutes before straining my eyes and eventually getting headaches. BTW: Netbeans' about box doesn't really help identify your Java version. "Java: 1.6.0_10-ea; Java HotSpot(TM) Client VM 11.0-b11" doesn't tell me which update 10 build you're using. I'm running build 25, what about you?
BTW: How do you switch anti-aliasing on and off? PS: You won't notice this problem with the default profile because of the white background. You really must use "Norway Today" to reproduce it.
vstejskal, I've answered all your questions and this issue is rather annoying. Is there anything more I can do on my side to speed up a fix? I am concerned that the longer we get away from the date it got introduced, the harder it will be to track down. At the very least, can we get someone from the Netbeans staff to try to reproduce the problem under Windows XP with the latest dev build? I want to figure out whether this is Vista-specific or whether it occurs elsewhere.
I found two possible workarounds: 1) If the default font is Monospace, you need to disable anti-aliasing across the entire OS by going into Control Panel -> Appearance and Personalization -> Personalization -> Window Color and Appearance -> Open classic appearance properties for more colors -> Appearance Settings -> Effects -> uncheck "Use the following method to smooth edges of screen fonts" This will result in jagged but readable fonts. If you do not disable Cleartype the Monospace font will render blurry and hurts the eyes. 2) Change the default font from Monospace to Consolas which renders much nicer.
This issue is also reproducible on 6.5 M1.
*** Issue 139383 has been marked as a duplicate of this issue. ***
*** Issue 142211 has been marked as a duplicate of this issue. ***
Hi! Try to start NetBeans from the command line using: "netbeans.exe -J-Dswing-aatext=false" or "./netbeans -J-Dswing-aatext=false" This should disable anti-aliasing, right?
Yes that will disable anti-aliasing. Then you have to put up with the case of the jaggies ;) Has any Netbeans staff been able to reproduce this problem?
*** Issue 144034 has been marked as a duplicate of this issue. ***
I don't know if this posting will help any, but I followed a suggestion from vstejskal re: issue 144034 (which has been marked as a duplicate of this issue) to set a new userdir (using the 6.5 beta, by changing entry in netbeans.conf) and it fixed my IDE font problems: Here's my message on that issue: "As you suggested, I have changes the userdir and the ide fonts are rendered perfectly. I guess it must be some setting brought in from 6.1 that screws up the 6.5 ide font rendering? I now have a usable IDE - many thanks. Nevertheless, the importing of previous settings should not screw the IDE up like this, so I guess there is some work to do to stop that happening?"
I guess I need to give this issue a second try. When I first reported it using a fresh userdir (not importing from 6.1 or anything) did not fix the problem. Perhaps something has changed in the meantime. I'll report back soon with what I find.
I can still reproduce this bug in 6.5 dev build 200808190201 and 6.5 M2 with a fresh userdir. BTW: I should clarify, there are three kinds of renderings modes you should watch out for: 1) Anti-aliasing fully disabled 2) Emulated Anti-aliasing enabled (Rendered by Java) 3) Native Anti-aliasing enabled (Rendered by Windows) The bug I am reporting is that #3 used to work in Netbeans 6.1 and now only #2 works. The rendering is noticeably worse as the screenshots show. deftex, are you sure you're not simply moving from #1 to #2? Also, what operating system are you using?
By the way, Netbeans 6.5 dev build June 11th, 2008 had anti-aliasing working perfectly (I used a local copy to confirm this fact) and if I remember correctly the dev build around two weeks later had it was broken. At the very least you now have a specific version number where you know this was working. Hopefully you can diff against it to see what's changed.
This may sound stupid, but how do you tell the difference between #2 and #3? What should we be looking at? Is this even possible on linux? Can this somehow be controlled on the JDK level (eg. some property)? Thanks
Take a look at the screenshots I've attached. If you compare the letters "e" and "c" in the screenshots you will notice that in screenshot.png they are semi-transparent and more jagged than in screenshot2.png. In the latter, all characters are solid (easier to read) and smooth. Take a look at http://www.ffnn.nl/pages/articles/java/java-2-se-6.0-aesthetics-preview.php and http://www.nabble.com/Menu-fonts,-ClearType,-and-Windows-td12959314.html for more discussion with respect to what happens on Linux. In short, I don't think there is a system property for toggling the behavior and it seems that native rendering (#3) only occurs under Windows. Linux only supports sub-pixel rendering (#2)
Given the number of duplicates, I would say this should be raised to P2.
From Ruby alias discussion: I'm a bit puzzled. You said that Native Windows rendering was working for you a while back with a specific NetBeans build. That should not be possible - that is only supported by the upcoming Java 6 Update N release. I wrote about this (as a followup to an older font rendering thread referenced from this issue) here: http://www.nabble.com/Re%3A-Menu-fonts%2C-ClearType%2C-and-Windows----Hopefully-Fixed-p15704395.html Is it possible that the given NetBeans build happened to be pointing (via etc/netbeans.conf's jdkhome setting) to an early access release of JDK6updateN, and your other builds are not? What happens if you try a current 6.5 build with JDK6 update N, does it look the way you want?
I've been using Java6 Update N for all releases mentioned in this issue, which is why I expect this to work. But thanks for pointing it out, can someone from the Netbeans staff please try reproducing this issue with the Update N release?
I agree with pjiricka...
*** Issue 145683 has been marked as a duplicate of this issue. ***
*** Issue 145450 has been marked as a duplicate of this issue. ***
Vito, please take a look at it. Thanks.
I tried it on Windows Vista and I can confirm that the native antialiasing is not used in Netbeans editor. I checked both Norway Today and the default themes and here are my findings: 1. The JVM correctly recognizes -Dswing.aatext=<true|false> flag and turns antialiasing on/off. 2. By default (no swing.aatext specified) antialiasing is on. 3. However, it is always only the emulated antialising and never the native Windows one. I checked that by taking screenshots of Netbeans, saving them as PNG and zooming in on text to see what pixels are there. If I get Gilis explanation correctly pixels around text rendered with the emulated antialising algorithm are all in grades of shade (with white background), while with native antialiasing the pixels are in different colours. Now, the problem really seems to be only in the Netbeans editor, because when I zoomed in on the main menu bar I could see coloured pixels around text. But in the editor only the grades of shade. I have no idea why this is so, but I'm pulling the sourcebase now and will experiment with the rendering hints we use in the editor and see if I can find the right ones. Product Version: NetBeans IDE Dev (Build 200809020201) Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b15 System: Windows Vista version 6.0 running on x86; Cp1250; cs_CZ (nb) Userdir: C:\Users\vita\.netbeans\dev java version "1.6.0_10-rc" Java(TM) SE Runtime Environment (build 1.6.0_10-rc-b28) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
Not sure but this could be because other components are from the windows L&F while our editor is rendered entirely by us. I'll try to find out whether there's any special hint in the rendering hints map that the windows L&F could turn on when on windows.
I just pushed fix for this. According to my tests the editor is now using native antialiasing (if available). That is, I can now see cloured pixels around text in the editor. Gili (and others), could you please download a build, which contains the changset below and confirm that the antialiasing in Netbeans editor is now working according to your expectations? You can either use Hudson trunk builds from http://deadlock.netbeans.org/hudson/job/trunk/ or development builds from netbeans.org. Thanks http://hg.netbeans.org/main/rev/06619e663be5
I tried hudson-trunk-3663 on Mac OS X. Glyphs in editor are different from previous one (I used 3658). It looks antialiasing is not working.
Created attachment 68956 [details] screenshot of hudson-trunk-3663, JDK1.5.0_13-119, Mac OS X 10.5.4
Integrated into 'main-golden', will be available in build *200809031401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/06619e663be5 User: Vita Stejskal <vstejskal@netbeans.org> Log: #137845: use system default value for KEY_TEXT_ANTIALIASING unless forced to turn it off
masaki, Can you please attach a screenshot of what it looked like before? That is, the exact same content using the two different builds.
Created attachment 68976 [details] this is a screenshot of trunk 3658 build on Mac OS X
The trunk 3658 version does look softer, though not as good as I would expect from a native renderer. For example, take a look at "URLDisplayer" in the import section. It looks a bit fuzzy on my monitor. Taking a look at the changeset, I'm not sure why this would break anything under MacOSX. I assume you have anti-aliasing enabled in your OS (the equivalent of ClearType)? I'm still waiting for the main-golden code drop to confirm whether this fixes anything under Windows because I don't know how to install the hudson builds. Once we establish that we should investigate whether we see the same problem when comparing JDK 1.5 to 1.6 update 10 on Windows. Ideally we should find out whether this is a JDK version issue or a platform specific issue. I think it is fair to say this issue needs to be reopened until it works fine under Mac as well.
Hi Vita, on Mac OSX, change 06619e663be5 made things worse. I think it's best to special-handle that platform. The JVM will do antialiasing on its own, so on that platform it's probably best to leave the JDK aliasing flags alone.
Is there such a thing as Java 6 or Java6 update 10 on MacOSX? Has anyone tried this fix against those versions?
> needs to be reopened until it works fine under Mac as well Sure. I've another independent complaint from Tor that antialiasing is not working on Mac. > Taking a look at the changeset, I'm not sure why this would break anything under MacOSX. I assume you have > anti-aliasing enabled in your OS (the equivalent of ClearType)? Well, it could. With the changeset if there are any desktopHints they will be used without change unless atialiasing is explicitly turned off. The problem could be that Mac OS X uses JDK5, where antialiasing is turned off by default. Anyway, Masaki, could you please start Netbeans with '-J-Dorg.netbeans.modules.editor.settings.storage.fontscolors.CompositeFCS.level=FINE' and send me the log file (or attach it here)? It should contain a message saying whether the antialiasing is on or off and why. Thanks
When I start the IDE on OSX with that logging flag, I get these two entries in the console: FINE [org.netbeans.modules.editor.settings.storage.fontscolors.CompositeFCS]: Text Antialiasing was set ON by running on Mac OSX. FINE [org.netbeans.modules.editor.settings.storage.fontscolors.CompositeFCS]: Text Antialiasing was set ON by running on Mac OSX.
Hallelujah! My eyes.... they can see again! The latest build fixes ClearType rendering under Windows Vista 64-bit :) By the way, I posted a question to the Java2D team regarding ClearType rendering: http://forums.java.net/jive/thread.jspa?threadID=46572 Hopefully there is a more solid way of patching this... At the very least we should discuss what action to take on platforms that have anti-aliasing disabled by default, such as JDK5 (which is mainstream on Mac). If the Netbeans team wishes to override this default (I suspect this is what users want) then you should probably update the patch accordingly. vstejskal, thanks again for fixing this issue! It's been bugging me for a very long time now :)
Thanks to everybody for testing this. I just pushed another patch to trunk. Tested myself on Ubuntu and Vista with JDK5 and 6. Tor, Masaki, could you please try it on Mac. The changeset is http://hg.netbeans.org/main/rev/327e74fde286. If you guys confirm that text AA is back to normal on Mac I'll close this issue as FIXED. Thanks Here is a little story for those who have time to read it: > Hi Vita, on Mac OSX, change 06619e663be5 made things worse. I think it's best to special-handle that platform. > The JVM will do antialiasing on its own, so on that platform it's probably best to leave the JDK aliasing flags alone. I understand that JVM can do antialiasing by itself, if it is instructed to do so. And that is the problem. JDK5 does not detect OS Font AA settings at all, JDK6 can detect these settings on _some_ systems. So, the problem is not in the rendering itself, but in detecting the rendering hints that the JVM should used. JDK6 seem to detect OS settings correctly on Windows (I tried Vista, but from what I've read it should work well on XP too) and GTK (maybe others too). But apparently on Mac the JDK does not detect the OS AA settings (according to Tor's log messages posted here). We (Netbeans) have been advertising 'swing.aatext' system property for turning text AA on/off in JVM. According to what I've learned so far this is wrong. The property does nothing; JVM does not recognize it (I can confirm this on JDK 1.5.0_14 and 1.6.0_10ea). However, Netbeans do (!) recognize this property and try to set correct rendering hints. The problem here is that the rendering hint used for text AA are not a simple on/off flag. There is a handful values that you can use and which have to do with how your screen (LCD) physically works with pixels. Don't ask details, because I don't understand it at all. So, we can comfortably tell JVM to turn text AA off if -Dswing.aatext=false, but we have no idea what hint we should use when -Dswing.aatext=true and so we defensively use the hint that turns on the emulated AA mode. This is the best we can do (without some fancy GUI customizer) if JVM can't detect OS AA settings. On the other hand if JVM detected the OS AA settings and they contain one of the 'AA is on' values we should not interfere. Some interesting links: http://java.sun.com/javase/6/docs/api/java/awt/doc-files/DesktopProperties.html http://java.sun.com/javase/6/docs/technotes/guides/2d/flags.html#aaFonts
vstejskal, what was the value of KEY_TEXT_ANTIALIASING before Netbeans changed it to VALUE_TEXT_ANTIALIAS_ON? Also be sure to check the discussion at http://forums.java.net/jive/thread.jspa?messageID=297224
Hi Vita, I updated my build and everything is fine on OSX now.
New build is fine on my Mac too. Great!
Integrated into 'main-golden', will be available in build *200809050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/327e74fde286 User: Vita Stejskal <vstejskal@netbeans.org> Log: #137845: a few more adjustments to correctly support text AA on Mac OS; also ignoring the old 'textAntialiasing' setting
Masaki, Tor, thanks for checking. I'm marking this as FIXED. > vstejskal, what was the value of KEY_TEXT_ANTIALIASING before Netbeans changed it to VALUE_TEXT_ANTIALIAS_ON? With JDK6 on Vista and Ubuntu/Gnome it is exactly what I specify in the OS. That is, on my laptop it's VALUE_TEXT_ANTIALIAS_LCD_HRGB. I tried changing the OS settings and they were reflected, so the detection algorithm in JDK6 works ok. As far as I understand it VALUE_TEXT_ANTIALIAS_ON refers to the emulated AA mode and has been available at least since JDK5. Basically, the values *_OFF and *_DEFAULT mean that AA is off, any other value (a) means that AA is on and (b) specifies the actual rendering algorithm used. > Also be sure to check the discussion at http://forums.java.net/jive/thread.jspa?messageID=297224 Yes, I'm following that discussion.
There is a typo in your patch ;) Search for "oficial". Also, I filed issue 146336 for handling runtime changes to the anti-aliasing setting. Right now it hangs Netbeans hard and the entire IDE must be killed. It could be really hanging or perhaps the rendering is just dieing somewhere. Either way this needs to be fixed.
>As far as I understand it VALUE_TEXT_ANTIALIAS_ON refers to the emulated AA mode > and has been available at least since JDK5. I can tell you quite definitely that "ON" means use a greyscale AA algorithm and goes back to JDk 1.2 (1998). People who complaine about "fuzziness" were perhaps seeing the editor (or something else) hardwiring the value to "ON", rather than the desktop setting. The NB editor used to do this once upon a time. > Basically, the values *_OFF and *_DEFAULT mean that AA is off, True for sun implementations, but I believe Apple use something else as default. > any other value (a) means that AA is on and (b) specifies the actual rendering algorithm used. That is correct, although values like "GASP" (== windows 'Standard Font Smoothing') obeys info in the font which typically says do B&W at screen resolutions. People find this surprising buts its correct. -phil.