JDK-4880097 : Need to dynamically configure java2d acceleration based on startup tests
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2003-06-17
  • Updated: 2004-06-04
  • Resolved: 2003-07-29
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 tigerFixed
Related Reports
Relates :  
JDK-4713003 - 1.4.1 REGRESSION: Windows XP freezes on Java application exit/draw
Relates :  
JDK-4867219 - Any Java UI freezes Windows on init
Relates :  
JDK-4838939 - java.exe - DLL Initialization Failed
Description
Some problems using hardware acceleration APIs are unforseeable during implementation of the java2d library.  For example, some video cards or drivers can cause the application or system to crash (see bug 4713003 for a great
example of this).  Some of these problems could be worked-around in java2d
(such as the fix to 4713003), but some have no known fix other than updating
graphics drivers.

In any case, since we cannot test on every possible OS/motherboard/videocard/
driver version prior to release, we should have some scheme in place to 
automatically detect and workaround problems.  We should run a test
at startup that tries various simple things, record the results in some
persistent way, and refer to those results in future runs of java2d.

For example, if Java crashes when loading ddraw.dll (see bug 4838939), we should detect that the first time and in future runs simply avoid loading that dll.

For now, this problem is primarily on Windows.  There may be similar issues 
on other platforms eventually, but for now we just need to solve this for Windows.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b13
14-06-2004
EVALUATION Prior to initializing ddraw, we run a startup check. In this test, we first query the display device we are one (one test for each display in the system). We then check whether that device has already been registered in the registry by us. If so, we check the values there to see what acceleration to enable or disable. Then we proceed with initialization, skipping those things that were recorded in the registry as problematic. If the current display device is not in the registry, then we need to run a test. First, we record the device in the registry and mark that we have not yet run the test. Then we load ddraw. if this succeeds, we do some simple ddraw tests. if these succeed, we create a d3d device. If this succeeds, we do various d3d tests. And so on, until we have finished our battery of simple tests. At the end of the test, we record the rest of the information and then continue initialization appropriately. A test failure does not necessarily mean that we cannot do other things with hw acceleration. For example, a card may have poor d3d line quality but handle texture map blitting fine. We just mark that we sould not enable line acceleration through d3d but that texture map blits are okay. A terminal failure (such as an app crash or system crash) gets recorded in the registry implicitly. The next time we run, we see that we recorded the display device in the registry, that we started some test, but that we did not finish it; this indicates that we should not enable whatever that test enabled. So if loading ddraw.dll crashes the app or system, the next time we run we will not even attempt this operation but will simply continue running without ddraw acceleration. If the user installs a new video card, we will notice that in the startup check because we have not recorded information about this device before. if the user upgrades their driver version, we will probably not notice that upgrade; this is because the API used to query the driver version can take anywhere from 250 ms to 15 seconds (!) in my experience; this is not something we want to do at every startup, obviously. We should have some way of forcing the startup test to be re-run (environment variable or whatever) just as a means of resetting the system, but in general any failure on a particular piece of hardware should result in disabling acceleration for that device. Better to run robustly from then on than to chance another failure. The registry is a good place for this info because it is fast and persistent. We could use the Preferences API, but loading those classes is more than we want to do at every startup. Also, we are already in native code anyway, so using the platform-specific registry approach is not too arduous. ###@###.### 2003-06-17
17-06-2003