|
Replies:
3
-
Last Post:
Jan 13, 2009 1:28 PM
by: rossjudson
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
Text anti-aliasing settings/Changing LAF
Posted:
Nov 17, 2008 10:44 AM
|
|
|
I'm having issues with the anti-aliasing of text in Java 6. Depending on the order in which I instantiate Swing components, change look and feel (to getSystemLookAndFeelClassName, in this case WindowsLookAndFeel), what have you, I'm getting either aliased (bad) or anti-aliased (good) text in my menus, buttons, etc.
I'm still sorting through some of the order, but I'd appreciate if anyone had pointers on how to look. Key findings so far:
1. It's sufficient to get anti-aliased text to put
Toolkit.getDefaultToolkit().getDesktopProperty("awt.font.desktophints");
before any other code. It's also sufficient to instantiate a JFrame before setting the Windows look and feel.
2. When the anti-aliased text is shown correctly, the system's UIDefaults contains an AATextInfoPropertyKey entry. When it's not shown, it doesn't.
Thanks much for any leads,
Michael
|
|
|
|
|
|
|
Re: Text anti-aliasing settings/Changing LAF
Posted:
Nov 17, 2008 11:15 AM
in response to: kazoobrewer
|
|
|
> Depending on the order in which I
> instantiate Swing components
This should only depend on the look-and-feel. This functionality is available under Metal (and all its derivatives), GTK and Windows look-and-feels. Third-party LAFs that extend Basic do not have this functionality built in unless they do some (completely unnecessary - see below) coding.
>
> 1. It's sufficient to get anti-aliased text to put
> > Toolkit.getDefaultToolkit().getDesktopProperty("awt.fon
> t.desktophints");
>
> before any other code. It's also sufficient to
> instantiate a JFrame before setting the Windows look
> and feel.
Post a complete (<100 lines) test app that illustrates your issue.
> 2. When the anti-aliased text is shown correctly,
> the system's UIDefaults contains an
> AATextInfoPropertyKey entry. When it's not shown, it
> doesn't.
I have addressed this issue before [1]. I had a quite unproductive discussion on the "free rides" that Metal, Windows and GTK look-and-feels get by their "virtue" of being core look-and-feels as far as the desktop AA settings go. You can see the discussion at [2] and the RFE that i filed at [3]. This discussion has not led to where i hoped it would (where the third-party look-and-feels extending Basic would get the same functionality as the third-party look-and-feels extending Metal). So i had to resort to injecting the hint installation myself.
In my opinion, the whole thing about exposing API to set the text rasterization hints is unnecessary. Java2D should use the native rasterizer on *all* platforms for all text rasterization APIs. This is partially done in 6u10 on Windows when the awt.font.desktophints property is used as mentioned in the original links. Hopefully, JDK 7 will remove the bundled rasterizer(s), deprecate the existing rendering hints (in addition to the desktop property) and make them no-ops and start using native text rasterization exclusively based on the current settings of the user desktop environment.
Kirill
[1] http://forums.java.net/jive/thread.jspa?threadID=46948
[2] http://www.javalobby.org/java/forums/t87243.html?start=0
[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6506298
|
|
|
|
|
|
|
|
|
Re: Text anti-aliasing settings/Changing LAF
Posted:
Nov 17, 2008 2:41 PM
in response to: kirillcool
|
|
|
> Hopefully, JDK 7 will remove
> the bundled rasterizer(s), deprecate the existing
> rendering hints (in addition to the desktop property)
> and make them no-ops and start using native text
> rasterization exclusively based on the current
> settings of the user desktop environment.
Well, if it would be that simple 
|
|
|
|
|
|
|
|
|
Re: Text anti-aliasing settings/Changing LAF
Posted:
Jan 13, 2009 1:28 PM
in response to: linuxhippy
|
|
|
Most of the time you do want this behavior, EXCEPT when you want to ensure geometric stability of the text you are drawing. At that point you want to switch over to Glyph-based rendering, and use geometric antialiasing, not text anti-aliasing.
If you are drawing animated text under a transform, this avoids "popping" in weight appearance.
When rendering text you can aim for legibility (at the cost of geometric precision), or geometry (at the cost of legibility).
|
|
|
|
|
java.net RSS
