JDK-6311320 : Swing applications are blank or blurry when fullscreen-AA is enabled in video card settings
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-08-15
  • Updated: 2014-02-27
  • Resolved: 2006-05-03
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.
Other
5.0u8 b01Fixed
Related Reports
Relates :  
JDK-6213204 - Starting any java program causes the screen to become blurred
Relates :  
JDK-6267861 - Blank/grey (empty) Java Control Panel screen after JRE installation
Description
This bug has been filed elswhere; I am opening up this new bug report to avoid the confusion of the previous closed bugs.

In particular, see bugs 6267861 (closed as a dup) and 6213204.

The main issue is this:
Some users have tweaked the display control panel settings for their graphics chip to force-enable fullscreen anti-aliasing for all Direct3D applications.  This setting is disabled by default (the setting is usually "application controlled"), but can be manually adjusted by the user.  It is theoretically possible that games could also force-enable this unbeknownst to the user, but we have no way of knowing now whether this has happend; we'll just assume the users have adjusted the setting manually.

When this setting has been enabled, _all_ Direct3D applications end up rendering with "fullscreen anti-aliasing".  This means that Swing, too, uses this setting.  This has two possible outcomes in Swing applications:
- Some applications have correct content, but that content is blurry.  What the user sees is that the entire desktop will become blurry as soon as the Swing application is launched.  The contents of all of the applications will be correct, but the text will be so blurry as to be unreadable, or at least painful to read.
- Sometimes the overall desktop is not affected, but Swing applications come up with a blank screen.
The times that I saw the 'blurry' desktop effect, I was using a setting that does not appear to exist on my ATI Radeon 9700; the setting was "2xQ AA" (detailed in the evaluation of 6213204).  On my Radeon card, I just see the blank-window effect when any of the 2x/4x/6x settings are chosen in the Direct3D tab of the Advanced dialog in the display control panel settings.

The reason for the next bug report is that the root issue, our use of Direct3D, has been "fixed" in Mustang; we no longer enable Direct3D by default.  This means that most users (especially those using the control panel, as originally reported in 6267861) will never see this problem because we do not trigger the Direct3D situation that causes it.  
However, we should still fix this problem in older releases, such as the 5.0 update releases.  Since Direct3D is enabled by default in those releases, users will see this problem if they happen to have the display control panel settings changed as noted here.

Note: The best fix for this problem is for users to change their display control panel settings to be "Application perference" for Direct3D anti-aliasing; there is no good reason to force this on for all Direct3D applications, and will cause problems for any or all applications that happen to use Direct3D (like Swing).  Having said, that we should fix the problem for those users that continue to have this switch enabled (maybe because they do not realize it's been changed).
Comments
EVALUATION As part of this fix, we need to force d3d on when transaccel is enabled (since we are now disabling d3d by default, we need to enable it when appropriate).
15-12-2005
EVALUATION The simple fix here is to disable Direct3D for 5.0. The main benefit of Direct3D acceleration was that lines were somewhat faster than they were prior to having Direct3D support. Previously, only horizontal and vertical lines were accelerated (through DirectDraw), and horizontal lines went through GDI rendering to the ddraw back buffer. This ended up being a bottleneck for applications that did serious line rendering. However, lines through Direct3D still are not as fast as we would like them to be (not as fast, for example, as lines rendered to a BufferedImage through software routines; putting pixels into a VRAM-based back buffer is simply not a fast operation), and the number of applications doing line-intensive rendering is arguably quite small. These applications have a reasonable workaround to stick with current functionality; they can use the -Dsun.java2d.d3d=true flag to force-enable Direct3D. Meanwhile, the vast majority of applications, which see no tangible benefit from Direct3D acceleration, should run just as fast without this acceleration enabled. We should do some sanity-checking on performance here, but based on previous experience I would expect performance of Swing applications to be as good or better with this "fix" (better because simply enabling Direct3D can sometimes slow down performance for software or DirectDraw applications). Line-intensive applications will probably suffer to some degree. Note that this "fix" is only for older releases. Mustang already has a better "fix" of not enabling Direct3D by default, and we are continuing to look into a more comprehensive fix which would work around the problem even when d3d is enabled.
15-08-2005