JDK-4839812 : messed up display of Plugin Control Panel and Sun Java Console
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1,1.4.1_02,1.4.2,1.4.2_01
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2003-03-29
  • Updated: 2003-06-27
  • Resolved: 2003-05-01
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 Other
1.4.1_05 05Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4856786 - Screen updates around mouse pointer not working (Similar to 4160291)
Duplicate :  
JDK-4886066 - Paint bugs with JTextField, JInternalFrame on Tablet PC using JRE 1.4.x
Duplicate :  
JDK-4883869 - Java repaint/redraw fails on Windows 2000, making Java apps unusable
Duplicate :  
JDK-4856113 - Severely corrupted graphics on Windows
Duplicate :  
JDK-4865039 - painting issues on windows XP
Relates :  
JDK-4985630 - Trident video card causes rendering artifacts on jdk1.5 (Windows only)
Description

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
position.

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)

-Dsun.java2d.nod3d=true
  Java Console now works fine,
  Plugin Control Panel still incorrectly painting

-Dsun.java2d.noddraw=true
  both Java Console and Plugin Control Panel still behaving badly.

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

Platform configuration:

CPU:
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
-008B.22ICD


###@###.### 2003-03-31
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_05 mantis-rc tiger FIXED IN: 1.4.1_05 mantis-rc tiger INTEGRATED IN: 1.4.1_05 mantis-b22 mantis-rc tiger tiger-b08
14-06-2004
PUBLIC COMMENTS Name: dm26566 Date: 03/29/2003 . ======================================================================
10-06-2004
WORK AROUND 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: -Dsun.java2d.d3d=false 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
26-06-2003
EVALUATION 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 mantis. 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
25-04-2003