United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4839812 : messed up display of Plugin Control Panel and Sun Java Console

Submit Date:
Updated Date:
Project Name:
Resolved Date:
Affected Versions:
Fixed Versions:
1.4.1_05 (05)

Related Reports

Sub Tasks


Name: dm26566			Date: 03/29/2003

I have installed mantis b19 on my Toshiba Portege 2000. When I
attempts to bring up either the "Sun Java Console" or the
"Plugin Control Panel" a grey area is displayed.

If I move that area, the drop-to position remains grey, but
the correct image is repainted into the old space. The new
grey area is active, but all repaint actions occur in old

Also, sometimes scrollbars behave in reverse manner: scroll up
will scroll down. Even stranger, sometimes the horizontal scroll
bars affect the vertical display.

Applets contained within the browser windows and applications
run fine.

My laptop has the following configuration:
16 M Video ram w/ Trident Video Accelerator CyberBlade XP Ai1
graphics card
windows 2000 SP2


At Jeannette's request, I ran with addtional settings (set in the
Plugin Control panel)

  Java Console now works fine,
  Plugin Control Panel still incorrectly painting

  both Java Console and Plugin Control Panel still behaving badly.

Also, here is the information from the Java2D PlatformInfo tool:

Platform configuration:

Intel 32bit
Single Processor
Processor Speed: 746 MHz

Operating System:
Windows 2000 (version 5.0 Service Pack 3 (Build 2195))

DirectX version: DirectX 8.1 or greater

DirectX display devices:
Device 0:
  Resolution (width x height x depth): 1600 x 1200 x 16
  Device driver tridxp.dll version 5.0.2195.135

GDI display devices:
Primary: Name = \\.\DISPLAY1, Description = Trident Video Accelerator CyberBlade XP Ai1  v5.9030

###@###.### 2003-03-31



BugTraq+ Release Management Values





Name: dm26566			Date: 03/29/2003



Disable Java2D's use of Direct3D at runtime by using the command-line flag -Dsun.java2d.d3d=false, for example:
	java -Dsun.java2d.d3d=false <class>
You can use this same flag inside of plugin, in the "Advanced" tab inside the "Java Runtime Parameters" text field, enter the same flag info:
Since the plugin control panel can be rather messed-up and unusable due to
this bug, you may also want to use the equivalent environment variable, J2D_D3D.
To do this, pull up the System control panel, go to the Advanced tab and
bring up the "Environment Variables" dialog box and enter a new variable named
J2D_D3D with the value false.  Or you can do this same thing on a temporary basis by simply setting the variable on a command tool:
	set J2D_D3D=false
Setting this environment variable for the system will also allow the control
panel to work (since every Java execution will use the value of that variable
to turn off d3d support and thus workaround this bug).

###@###.### 2003-04-25

A straightforward workaround (at least in Win2K) is:
Settings -> Control Panel -> Display -> Settings -> Advanced -> Troubleshooting.
Set "Hardware Acceleration" to "Disable all DirectDraw accelerations ..."

This workaround has a messaging advantage for customers: "The Trident video
adapter has a problem and needs to be adjusted" (which is true) vs. "Java
requires strange command-line flags to work right." The disadvantage is that it will affect performance of more than just Java.

###@###.### 2003-06-26

I don't think this is a plug-in bug.  We need java2d team to take a look at this.
###@###.### 2003-03-31

Mantis b19 plugin works fine on my Dell laptop.  Probably a specific issue
with Trident video cards.
###@###.### 2003-03-31

Definitely looks video-card specifc and seems to be tied to d3d functionality
introduced in the changes that went into 1.4.1_02 and 1.4.2 b7; previous
builds of both releases (and 1.4.0) work fine.  Also, using the d3d=false
flag makes everything work (better workaround than noddraw).

The effects are weird, though; they do not appear to have anything to do with
the 3d functionality we are using (just drawing d3d lines).  Instead, it seems
like simply enabling d3d for some drawing surfaces causes strange interaction
between ddraw and gdi.  For example, scrolling on the crayons panel in
SwingSet2 does nothing until you alt-tab to a different app, at which time
the SwingSet2 window updates with several scroll/paint events.  It is as 
if the window events are locked out on that window which the app is 
in the foreground, but released when the app is backgrounded.  This artifact
could explain why some graphics are being drawn in the wrong place while the
window is being moved around; we are perhaps not getting the drawing event
at the right time and then we are updating the screen some later time when
the window has moved, thus the drawing is in the wrong place relative to
the current location of the window.

If this is a driver bug, there is no more recent version of the driver on
the Toshiba site.

Sill investigating.
###@###.### 2003-04-03

I was able to reproduce the bug in a simple native app.  I forwarded the app 
to Trident tech support, who can hopefully shed more light on the subject.
From what I've seen so far, it seems like the driver is enabling some sort
of caching mechanism where they buffer up all calls into DirectX until one of a couple of events happen: locking/Unlocking the screen (which generally causes
the DirectX pipeline to flush) or rendering a d3d primitive.  In our Java2D code, we do not necessarily perform either of these operations with any regularity.  DirectX operations are generally either rectangular fills (using ddraw), blts (using ddraw), locks (but not the screen on win2k due to a cursor flicker fix), or lines (using d3d).  Locking an offscreen buffer may also force a flush; I have not investigated that.  On this graphics driver, lines are disabled due to quality issues so we do not even issue the d3d calls. 
One other item that seems to flush the cache is forcing the window to the
background; perhaps they want to make sure that an app is done rendering when other apps come to the foreground.

in any case, there is nothing wrong that we are doing that is causing this
situation; we appear to be causing it simply by creating the d3d device for the screen.  This puts the Trident driver in this strange mode.

The only alternatives that I can think of so far for "fixing" this problem in Java2D include:
	- enabling d3d for the screen only if the application is fullscreen/
	double-buffered.  This is the only situation in which we actually need
	d3d capability on the primary surface (since we generally do not perform
	direct3D operations directly to the screen; we use ddraw for
	Blts and GDI for direct rendering operations).
	A major problem with this (at least as far as risk-free fixes go)
	is that our single shared d3d context is created from the primary.
	So if we disable d3d for the primary surface, we need another
	mechanism for creating and sharing the d3d context.  This is not 
	unsolvable, but it does involve risks and testing to make sure that
	we handle all situations robustly (such as losing the offscreen surface
	for which we have created that d3d context).
	- detecting the Trident video card and disabling d3d capabilities
	in native code automatically (similar to what we do for NT4, since
	there is no hw d3d support on that OS).  This is an ugly hack because
	I would rather avoid driver/card-specific fixes in our code and
	(more importantly) we do not actually know all of the devices which
	are affected by this odd bug.  if this driver is used by all 
	Trident cards, then we should detect any trident video card and
	disable d3d.  On the other hand, if the bug is specific to 
	a particular trident chip (and the driver for that chip), then
	disabling d3d for all trident cards is a bit extreme.
My preference is the first fix above: find a way to share the d3d context
without enabling d3d for the primary surface.  But given the time in the Mantis
release and the testing required for this fix, I doubt this is a candidate for

Note: I am assuming that the problem is coming from enabling d3d on the
primary surface.  But I actually have not yet tested whether enabling
it only for offscreen surfaces also triggers this problem.  if it does,
then we are hosed for Trident overall, barring any clever fixes suggested
by the folks at Trident.  I should nail this down to see whether this
is even a fixable problem.

I've attached a DevStudio project TridentD3DCrash.zip that has both the
source code and executable for reproducing the problem.  Run the app.
Then hit the F5 key to execute a series of ddraw blts to the screen (which
won't appear on the problem platform).  then hit F6 to force a lock/unlock
event, which should cause all of the pent-up ddraw commands to spew forth.
hit F5 again (still not output).  now quit the app; after the window closes
down, all of the ddraw commands spew forth onto the open desktop.

###@###.### 2003-04-15

I've implemented a fix like the second one outlined above; we detect that
we are running on a "Trident Video Accelerator CyberBlade XP Ai1" graphics
card and automatically disable Direct3D support in Java2D (unless the
user has specifically forced d3d support on via the command-line flag
-Dsun.java2d.d3d=true or the environment variable J2D_D3D=true).  This
appears to work on the problem platform, so we should integrate this fix
possibly for 1.4.2 and definitely for 1.5 (until we have a better solution
for 1.5).

Note about the fix: we currently simply detect that there is one of these
cards on the system and disable d3d support globally. This should work for
this particular configuration, since the problem platform is a laptop that
would never have multiple graphics devices on it.  But if we take this
workaround approach for other problem cards/drivers, we should modify the
fix to be multimon-friendly and simply disable d3d on the suspect devices and
not the entire platform globally.

###@###.### 2003-04-25

Hardware and Software, Engineered to Work Together