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.

N/A

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.

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2004-01-30

I had a similar problem.  

My computer has the Via Tech VT8361/VT8601 Chipset for graphics.

The latest Windows XP driver does not work with Java, but the Trident Video Accelerator Blade 3D/ProMedia driver  works without any bugs.

Try switching the display driver to the Video Accelerator Blade 3D/ProMedia driver, which is one of the standard drivers installed by Windows XP when XP was originally installed.

It looks like Windows XP, when you run windows update, reccommends installing the Via Tech VT8361/VT8601 driver.

Since the driver name does not have the word, "Trident" in the name, the bug fix hack which relies on the driver name having the word, "Trident", does not get turned on.

A driver that is compatible to the Via Tech VT8361/VT8601 driver is the Trident Video Accelerator Blade 3D/ProMedia driver.

Since the latter driver has the word "Trident" in the name, the bug fix hack is turned on and Java works without any display bugs.

To make the bug fix more rhobust, the bug fix hack should probably also check for the "VT8361/VT8601" string being in the driver name.