JDK-4985630 : Trident video card causes rendering artifacts on jdk1.5 (Windows only)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2004-01-29
  • Updated: 2004-02-09
  • Resolved: 2004-02-09
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.0 b38Fixed
Related Reports
Relates :  
JDK-4839812 - messed up display of Plugin Control Panel and Sun Java Console
Description
This is an old problem that was fixed in 1.4.2 - see 4839812 for a lot more
information on this.

This problem reappeared in 1.5 because we changed the way that we store the graphics device names.  Our fix to 4839812 was to simply disable our use of d3d when we detected that we were running on a Trident card (hacky, but there doesn't seem to be a better fix for this hideous driver bug).  This worked in 1.4.2 because the hardcoded list of bad graphics devices (which currently consists only of "Trident Video Accelerator") exactly matched the start of the graphics device name (which began with the same string).

In 1.5, we store more information with the device name, so that we can identify which monitor we are on (for multimon cases) and what bit depth we are in.  This allows us to store hw-acceleration information persistently in the registry.  But since we store more info in the device name string, our simple pattern match algorithm fails and we do not detect when we are running on this graphics board.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b38 tiger-beta2
14-06-2004
EVALUATION Simple fix here: match if the bad device string (which we can generalize to "Trident") is found anywhere in the current device name. Also, I noticed (through the customer tests) that our mechanism of disabling d3d via the command-line or environment does not work in this case. We correctly set the useD3D variable to FALSE in native code, which prevents us from performing d3d operations, but we do not use that variable to determine whether to create a d3d-capable Primary surface. Since the creation of a d3d context on the primary is the key that triggers this Trident driver bug, disabling d3d on that configuration does not stop the artifact from occurring. The fix to this is to check both the deviceUseD3D flag (which we currently use) _and_ the global useD3D flag (which we currently ignore) when creating a d3d-capable primary surface. ###@###.### 2004-01-29 Actually, a better fix to the useD3D problem is to set the initial value of deviceUseD3D to the value of useD3D; that way, if d3d is globally disabled, then all devices will avoid using d3d. Or in the default case (or if d3d is manually globally enabled), each device will start out as d3d-capable, but may still be disabled later depending on device problems. ###@###.### 2004-01-30
30-01-2004