JDK-6477756 : GraphicsDevice.getConfigurations() is slow taking 3 or more seconds
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0,7u45
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_7
  • CPU: x86
  • Submitted: 2006-10-03
  • Updated: 2017-08-28
  • Resolved: 2016-05-17
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u112Fixed 9 b124Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
1.5.0_06
1.4.2 build 1.4.2-b28
1.6.0-beta2-86
1.5.0_07


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
Microsoft Windows 2000 [Version 5.00.2195]


EXTRA RELEVANT SYSTEM CONFIGURATION :
Occurs on all versions of Windows on single headed machines which we have tested it on. On a double headed Windows XP machine it does not occur.

A DESCRIPTION OF THE PROBLEM :
The first time GraphicsDevice.getConfigurations() is called on a single header machine it takes 3 to 5 seconds. If it is called again on the same machine in a different Java session it takes slightly less time. If it is called again in the same Java session it takes a few milliseconds.

This has previously been reported in 2000 but the bugs are marked as "fixed".  A 3 second delay does not sound like "fixed" to us.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the program supplied which calls GraphicsDevice.getConfigurations().

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect the program to print:


Starting....
Finished in 20 milliseconds


ACTUAL -
It actually prints:

Starting....
Finished in 3585 milliseconds


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/**
 * Program to demonstrate speed of GraphicsEnvironment.getConfigurations()
 */

import java.awt.* ;

public class Bug
{
public static void main(String args[])
  	{
        GraphicsEnvironment ge = GraphicsEnvironment
		               .getLocalGraphicsEnvironment()
			       ;
        GraphicsDevice[] gs = ge.getScreenDevices();
        for (int j = 0; j < gs.length; j++)
	   {
	   // Demonstrate problem:
	   // The first time that getConfigurations() is called
	   // it takes significant time.
	   // The second and subsequent calls in the same
	   // Java session are fast.
	   // Examples
	   // Windows 2000   1.7GHz Java 1.5.0_06    3355 ms
	   // Windows 2000   1.7GHz Java 1.4.2_08    3355 ms
	   // Windows XPSP2  2.4GHz Java 1.4.2       2700 ms
	   // Windows XPSP2  2.8GHz Java 1.5.0_06    3313 ms
                        // Windows 2000     1.0GHz   Java 1.6.0-beta2-b86 3703ms

	   System.err.println("Starting....") ;
	   long startTime = System.currentTimeMillis() ;
           GraphicsConfiguration[] gc = gs[j].getConfigurations();
	   System.err.println("Finished in "
			   + (System.currentTimeMillis() - startTime)
			   + " milliseconds"
			   ) ;
	   }
	}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Spin up a separate thread which Thread.sleep()s until the main startup has finished and then executes a GraphicsDevice.getConfigurations(). All subsequent calls now complete in a few milliseconds.

Comments
If there's a clear reason, for addressing this on JDK 6, and 7, then we can consider backports, but at this time there are no plans to address for JDK 5, 6, and 7.
2016-06-20

I can reproduce this only when running through the RDP. The first DescribePixelFormat takes up about 40-60 ms in any case. But in case of RDP all subsequent calls are also takes up that much time, so for 36 total pixel formats reported, this adds up to the 2+ seconds. This happens because DPF loads opengl32.dll and then frees it. In case of accelerated display it seems that this handle is cached somewhere perhaps in the driver. But in the GDI case each DPF call results in loading/freeing a library. Caching the handle eliminates this slowness, I need only to find a way to persist this between Java calls.
2016-05-17

Re-targeted back to "9" as P2 bug. In case this is not a P2 (but P3) can be re-targeted after de-prioritization
2016-03-25

It is not seen in jdk9 on windows7 System Info: windows 7 professional 2.7GHz $ javac Bug.java prsadhuk@PRSADHUK-IN /cygdrive/c/jdk9/client/build/windows-x86-normal-server-fastdebug $ ./jdk/bin/java Bug Starting.... Finished in 8 milliseconds $ ./jdk/bin/java -version java version "1.9.0-internal-fastdebug" Java(TM) SE Runtime Environment (build 1.9.0-internal-fastdebug-prsadhuk_2015_10_28_12_46-b00) Java HotSpot(TM) Server VM (build 1.9.0-internal-prsadhuk_2015_10_28_12_46-b00, mixed mode)
2015-11-02

Increased priority to P2. NetBeans continues gathering hundreds of duplicate slowness reports related to this issue. Please reevaluate possibility of the fix. Thanks. http://statistics.netbeans.org/exceptions/detail.do?id=199452
2014-02-18

could you please re-evaluate it?
2013-12-17

Many NetBeans users are running into the slowness of Win32GraphicsDevice.isPixFmtSupported, the related bug has been closed as a duplicate of this one. http://statistics.netbeans.org/exceptions/detail.do?id=176584 Please, prioritize work on this problem. Thanks.
2013-12-16

This bug is causing problems for Java 3D applications on Windows. Java 3D applications need to call GraphicsDevice.getBestConfiguration(template) which calls GraphicsDevice.getConfigurations(). Btw, for reasons we haven't yet fully determined, we don't see the slowdown when we load and initialize our native OpenGL rendering pipeline prior to calling GraphicsDevice.getConfigurations(). Once we figure out why this speeds things up, we may be able to come up with a workaround for this bug. See the following Java 3D bug on java.net for more information: https://java3d.dev.java.net/issues/show_bug.cgi?id=406
2007-04-18

EVALUATION With the suggested workaround (which elminats the offending win32 calls) the time is significantly improved (to, like, 0ms). The property was added with the fix for bug 4455041. However some applications which use OpenGL with Java may not work correctly.
2006-10-04

WORK AROUND Set the -Dsun.awt.nopixfmt=true property.
2006-10-04

EVALUATION The problem is that ::DescribePixelFormat Win32 call is slow - takes up to 60ms to complete. $ java -Xprof Bug Starting.... Finished in 2921 milliseconds Starting.... Finished in 2907 milliseconds Flat profile of 5.99 secs (557 total ticks): main Interpreted + native Method 91.6% 0 + 510 sun.awt.Win32GraphicsDevice.isPixFmtSupported 3.9% 0 + 22 sun.awt.Win32GraphicsDevice.getDefaultPixIDImpl 2.0% 0 + 11 sun.awt.Win32GraphicsEnvironment.initDisplay 1.8% 0 + 10 sun.awt.Win32GraphicsDevice.getMaxConfigsImpl 0.2% 0 + 1 java.io.WinNTFileSystem.checkAccess 0.2% 1 + 0 sun.reflect.DelegatingMethodAccessorImpl.invoke 0.2% 1 + 0 sun.java2d.loops.GraphicsPrimitiveMgr.initIDs 0.2% 0 + 1 java.lang.ClassLoader$NativeLibrary.load 100.0% 2 + 555 Total interpreted This bug is related to 4369234: GraphicsDevice.getConfigurations is very slow which mostly addressed the problem on solaris/linux part, but not on Windows. Since we could not improve the performance of ::DescribePixelFormat, we could consider not calling it, or doing it only conditionally if some property is set, for example. (I believe the pixel format id info is only needed for Java3D)
2006-10-03