JDK-6291810 : Enable sub-pixel LCD font smoothing on Windows 2000
  • Type: Enhancement
  • Component: docs
  • Sub-Component: guides
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2005-06-28
  • Updated: 2017-05-16
  • Resolved: 2005-09-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 betaFixed
Related Reports
Relates :  
JDK-6408759 - Antialiased fonts in Linux without Gnome
Description
A DESCRIPTION OF THE REQUEST :
Mustang looks at the desktop font smoothing settings and follows them for Java font smoothing. This means that despite the fact that Mustang is capable of sub-pixel LCD font smoothing on Windows 2000, it cannot be enabled because the desktop setting in Windows 2000 only exists for the ordinary grayscale smoothing. The code in awt_DesktopProperties.cpp explicitly checks for Windows XP or better before even querying about font smoothing type. This could easily be done by directly reading the correspondent Registry setting from HKCU/Control Panel/FontSmoothingType which doesn't exist on Windows 2000 by default but can be added manually.

JUSTIFICATION :
This would enable Java desktop applications to look much better than native Windows applications on Windows 2000, which is still very popular in enterprise and is going to remain so for several years.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
LCD sub-pixel font smoothing in Java should work on Windows 2000.
ACTUAL -
Currently only default grayscale font smoothing is enabled which looks bad on LCD screen on Windows 2000.
###@###.### 2005-06-28 17:51:07 GMT
Comments
EVALUATION We will be documenting the Java system property "awt.useSystemAAFontSettings" as follows : awt.useSystemAAFontSettings --------------------------- By default "awt.useSystemAAFontSettings" is "true", which means use whatever is the actual desktop setting, if any, but it can also be used to specify additional String values which map to java.awt.RenderingHint values for the key java.awt.RenderingHint.KEY_TEXT_ANTIALIASING as follows : System Property Value | java.awt.RenderingHint value "off"|"false"|"default" : VALUE_TEXT_ANTIALIAS_DEFAULT "on" : VALUE_TEXT_ANTIALIAS_ON "gasp" : VALUE_TEXT_ANTIALIAS_GASP "lcd"|"lcd_hrgb" : VALUE_TEXT_ANTIALIAS_LCD_HRGB "lcd_hbgr" : VALUE_TEXT_ANTIALIAS_LCD_HBGR "lcd_vrgb" : VALUE_TEXT_ANTIALIAS_LCD_VRGB "lcd_vbgr" : VALUE_TEXT_ANTIALIAS_LCD_VBGR When any of these values is set, actual desktop settings, if any, are ignored and the specified value is always used. It is also added to the list of "WebStart Secure Properties" so Webstarted programs can use it. So : "false" corresponds to disabling font smoothing on the desktop. "on" corresponds to Gnome Best shapes/Best contrast "gasp" corresponds to Windows "Standard" font smoothing "lcd" corresponds to Gnome's "subpixel smoothing" and Windows "ClearType" Whilst this may be useful for some situations on Gnome/XP etc and for testing its probably more useful on other desktops which for one reason or another don't have any (or some specific desired) capability. So this enables applications on (for example) Windows 2000, KDE and CDE desktops to specify LCD text, or indeed for any app to choose whatever they want. Since its a system property you don't have to rely on the developer - a sysadmin can set this. There is a separate RFE to address programmatic setting of this for Swing: 6302464: Allow programmatic enabling of subpixel anti-aliasing in Swing on ANY platform
08-09-2005
EVALUATION Note that we use the registry only for sub pixel orientation, the type of smoothing (none, standard, lcd) is obtained from a SystemParametersInfo call. I'd be somewhat surprised if on Windows 2000 that updating the registry would make that call would return the value corresponding to LCD smoothing. So what is being requested here means that on Windows 2000 regardless of what SystemParametersInfo returns we would have to query the registry to see if a particular key has been set. That is additional overhead that on almost every deployed system would not find anything. We would also need to figure out what is supposed to happen when users change their system settings and perhaps also think about what elements of this behaviour we'd have to carry forward to XP. Another point is we are in the process of adding API that lets apps find out the desktop settings. We'd need to consider whether this returned the "faked" setting or the real setting. So there's a number of implications here. Another point is that the purpose of this was to make the font rendering match native apps. This would diverge from that. If we step back and read the actual user request here it is to "enable Java desktop applications to look much better than native Windows applications on Windows 2000" So although some class of users may see a registry update as the most convenient way to propagate this behaviour, we could also look at it as one suggested way to implement the desired behaviour but not the only one. If all that is wanted is some way to flag to JDK to use LCD text then some JDK specific registry entry is at least possible. But another way that is less "desktop wide" is via a Java system property that requests a particular override of the desktop settings. That would need to be specified on a per-application basis. This would require at least the ability to update the command or jnlp file that starts the app, but I think this is my preferred solution as its also something that would be useful for any desktop environment that wanted this but couldn't get it from desktop settings. Current examples are KDE, CDE and other X desktop environments. The registry setting on the other hand is completely windows specific. Thinking more about the behaviour if the user updates desktop settings that if either of these approaches is used that it probably would be interpreted as overriding the changed setting just as it overrode the original setting. Incidentally, just as this request comes in on Jun-29-2005 I have just read that tomorrow Jun-30-2005 is that last day of full support for Windows 2000 from Microsoft .. from 1st July the clock is ticking down. This does not in any way mean that this RFE is less interesting or lower priority to JDK but it does mean that there is no likelihood that Microsoft themselves will backport LCD text to a Windows 2000 service pack. ###@###.### 2005-06-29 16:13:42 GMT ========================================== It needs to be noted that this RFE originated as a request to pick up non-standard registry entries so that Swing programs would act as if they were the desktop settings. This is useful for system administrators or others who need to affect the behaviour of existing programs. A System property can be recognised as "Secure" by Java Webstart so webstarted apps can use this too. Some developers have requested a complementary capability which is to be able to programmatically instruct Swing to ignore the desktop settings and instead to use application-specified rendering hints. This could perhaps be addressed through the UIDefaults mechanism but no RFE has yet been filed. We should see if both that and this this RFE can co-exist as they address different needs.
29-06-2005