United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6477756 : GraphicsDevice.getConfigurations() is slow taking 3 or more seconds

Details
Type:
Bug
Submit Date:
2006-10-03
Status:
Closed
Updated Date:
2017-08-28
Project Name:
JDK
Resolved Date:
2016-05-17
Component:
client-libs
OS:
windows_xp,windows_7
Sub-Component:
2d
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0,7u45
Fixed Versions:

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

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



Hardware and Software, Engineered to Work Together