JDK-6213204 : Starting any java program causes the screen to become blurred
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1,1.4.2,5.0,5.0u2,5.0u4
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-12-31
  • Updated: 2011-02-01
  • Resolved: 2005-10-18
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 b33Fixed
Related Reports
Duplicate :  
JDK-6267861 - Blank/grey (empty) Java Control Panel screen after JRE installation
Duplicate :  
JDK-5023096 - Empty(completely gray) Dialogs and Windows with ATI graphics card
Duplicate :  
JDK-6279985 - Text too small when Nvidia display driver D3D Antialiasing is on
Relates :  
JDK-5104393 - Provide d3d pipeline to improve runtime performance of Swing/2D
Relates :  
JDK-6311320 - Swing applications are blank or blurry when fullscreen-AA is enabled in video card settings
Description
FULL PRODUCT VERSION :
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
I am using a Geforce 6800 graphics card with the latest (66.93) version graphics driver from nvidia.

A DESCRIPTION OF THE PROBLEM :
Whenever i start any java program, either as an applet in a webbrowser or standalone, the display becomes blurred. Objects on the screen gets a "shadow" next to it, causing the blur-effect.

Also, it is impossible to playback a video when a java program is running.

Changing the color depth or resolution on the desktop causes the display to go back to normal. This is just a workaround, the bug occurs at any resolution or color depth.


REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 2004-12-31 06:02:15 GMT

---------------------------------------

From other reports I have seen on this issue, I believe this is caused by the display driver being set to always use anti-aliasing (as opposed to letting hte application determine whether to use this setting).  You can control this in the Display Control Panel (go to the Settings Tab, click the Advanced button, and then keep drilling down to find this nVidia-specific control; on my GeForce4 MX this is in a tab entitled "GeForce4 MX 420", where I click the "Additional Properties" button and then configure  the "3D Antialiasing Settings" tab pane).

I have not seen this in-house yet because we do not yet have this hardware.
I have tried experiments on both ATI and nVidia cards without seeing this problem yet, so I suspect that it is very hardware- or driver-specific to the 6800 family.  The effect I see on the GeForce4 MX card is that when I force antialiasing on (2x, 4x, etc.), any d3d app will be anti-aliased but the desktop itself is not.  It seems as though this behavior is different on the 6800, where the entire desktop is anti-aliased instead of just each d3d application.

###@###.### 2005-1-03 17:44:03 GMT

More info from the submitter allowed us to reproduce this in-house: you
must choose the "2xQ" antialiasing option.  When you choose this as
your global default on nVidia systems (at least my GeForce4 MX and 
a 6800 system), then running Java causes the whole screen to go blurry,
as reported.


###@###.### 2005-1-05 01:46:17 GMT
Comments
EVALUATION Further testing results: I installed the latest drivers from nVidia for my GF4 MX card and still did not see the problem. In fact, I do not even see AA being enabled for Java (much less clobbering the whole desktop). I assume there is something radically different between this card and the 6800 family of cards in 2 areas: - Even when we use d3d on the GF4 MX card, we do not trigger the forced AA settings. Perhaps this is because our use of the DirectDraw back buffer is incompatible with the way AA is implemented for d3d. For example, does our use of locking the back buffer (for rendering text and other non-accelerated operations) cause AA to be disabled for that drawing surface? - When I do see AA being enabled (in running simple d3d sample applications), it only affects that single application window, not the entire desktop. We should pick up one of these cards so that we can reproduce the problems and see what kind of fix we can provide. Something else of interest here: it seems that this set of drivers is enabling AA by default, instead of the driver settings I've seen with my card of having AA be application-controlled by default. Is nVidia changing the default settings for a specific set of cards? Or have the users tweaked these settings unknowingly? ###@###.### 2005-1-03 19:12:56 GMT Correction to above: the submitter had tweaked the default settings to specifically enable 2xQ AA globally. Also, more information on the cause. I did some debugging, and my quick take on this is that this side-effect of a blurry screen is coming from enabling the primary surface of directX to be d3d-enabled. This differs from typical usage of other d3d apps (which usually just enable their back buffer to be d3d-enabled). This would explain why a sample d3d app (such as the boids.exe example from the dx7 sdk) does not cause this artifact and Java does. I see the screen turning blurry when we make the initial call into directX to CreateSurface for the primary surface, where one of the flags on that surface is to be 3d-enabled. The only reason that the primary is currently d3d-enabled is to enable easier caching of the shared d3d context. We tend to release and recreate offscreen surfaces during surface-loss situations, so if we release a surface that has the shared context, it complicates the whole d3d context usage/recreation process, whereas we do not currently release the primary surface, so the shared context does not need to be recreated. However, if my theory above is correct, it seems like we should move to a model of having a 3d-unaware primary, like typical d3d applications, and find a way to cache the d3d context on some offscreen surface instead. Note that we will eventually move into a non-3d onscreen surface eventually since DX9 does not allow _any_ DirectX operations directly to the screen other than a simple buffer copy/flip. ###@###.### 2005-1-05 01:46:17 GMT Verified the theory above with a native test app; I was able to reproduce the blurry screen problem with a simple d3d app that created a d3d-enabled primary surface. When I changed the app to remove the DDSCAPS_3DDEVICE flag from the surface creation caps bits (thus making the primary surface d3d-unaware) the bug did not appear (the desktop did not become blurry). We are in the process of rewriting much of the core Direct3D code for Mustang; we should probably just fix this bug as part of those changes (or at least wait until those changes are complete since the same code we would need to change to fix this bug). Reassigning bug to engineer doing the d3d rewrite for now. ###@###.### 2005-1-05 02:09:44 GMT ###@###.### 2005-1-05 02:12:16 GMT This bug has been fixed as part the d3d pipeline rewrite. See bug 5104393: Provide d3d pipeline to improve runtime performance of Swing/2D ###@###.### 2005-04-09 00:34:51 GMT
03-01-2005
WORK AROUND I'm not 100% sure of these workarounds since I have yet to reproduce the problem locally, but a couple of workarounds that should work are: - Change the Display Control Panel settings to make sure that d3d anti-aliasing is only enabled by the application itself (instead of being forced on for all d3d applications). - We (Java2D) are probably triggering the problem through our use of Direct3D. You can tell us not to use Direct3D by running a java application with the command-line flag: -Dsun.java2d.d3d=false ###@###.### 2005-1-03 17:44:03 GMT
03-01-2005