JDK-4369234 : GraphicsDevice.getConfigurations is very slow
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.3.0,1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.6,solaris_8
  • CPU: sparc
  • Submitted: 2000-09-07
  • Updated: 2000-11-23
  • Resolved: 2000-09-25
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.3.1 betaFixed 1.4.0Fixed
Related Reports
Duplicate :  
JDK-4373692 - JDesktopPane paint slow in Solaris than WIndows platform
Relates :  
JDK-6477756 - GraphicsDevice.getConfigurations() is slow taking 3 or more seconds
Description
This is a performance regression from 1.2.2 to 1.3 that we just tracked down to
the actual routine in question.  We had noticed longer start up times on Solaris, but attributed that to other factors (HotSpot).

On JDK 1.2.2 on Solaris, the GraphicsDevice.getConfigurations method takes
on the order of 4 milliseconds (0.004 seconds) to run.  On Kestrel and
Merlin, it takes over 8 seconds on a 360 Mhz dual-processor Ultra 60 / Elite3D.
The problem occurs on Windows, but is not as noticeable--probably because only
a single GraphicsConfiguration is returned on windows versus 12 on Solaris.
The majority of the time seems to be in creating the X11GraphicsConfig objects.


kevin.rushforth@Eng 2000-09-07

To reproduce this, run the attached program.



kelvin.chung@eng 2000-09-08
Under window2000, GraphicsDevice.getBestConfiguration()
hangs the machine in some Java3D test.
I put some debug statement and it didn't get into
the callback 

In GraphicsConfigTemplate3D
 public GraphicsConfiguration
      getBestConfiguration(GraphicsConfiguration[] gc)

This can be reproduce under the DirectX version of Java3D
using the test
/home/tlchung/j3d/programs/examples/GeometryByReference>java ImageComponentByReferenceTest

and when all the library .jar & .dll  is install under jre/
If I set PATH or CLASSPATH install of install the library
under jre than this bug can't reliably reproduce.

Also this bug only happen when it run as application using java.
If I use appletviewer or inside Netscape the program will not
hang.

No such problem under jdk1.2.2
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird ladybird-beta merlin-beta FIXED IN: ladybird-beta merlin-beta INTEGRATED IN: ladybird-beta merlin-beta
14-06-2004
EVALUATION I've profiled X11GraphicsDevice.getConfigurations and found out that we spend most of our time in creating X11GraphicsConfig objects, specifically, in the native method init(visualNum, screen). Creating one such an object could take up to 2 seconds on my Ultra 60 with ffb video board (it's even worse on Ultra 1). I've used Workshop profiler to profile the native code: Here is a stack trace: X11GraphicsConfig(X11GraphicsDevice dev, int visualNum); init(visualNum, screen); --- native code: Java_sun_awt_X11GraphicsConfig_init(..) - awt_GraphicsEnv.c awtJNI_CreateColorData(..) - color.c awt_allocate_colors(..) - color.c img_makePalette(..) - img_colors.c handle_biggest_offenders - img_colors.c find_nearest - img_colors.c (this is one of several possible ways, but they all end up calling find_nearest in a loop) Almost all of our time we spend in find_nearest function. I've figured that we probably won't be able to make significant speed improvements in this code (correct me if I'm wrong) and switched to another way of fixing the problem: deferring calls to awtJNI_CreateColorData to the point where it's really needed. In 1.2.2 awtJNI_CreateColorData is being called from the following stack: X11GC.getColorModel() awt_GraphcsEnv.c:_makeColorModel awt_GraphcsEnv.c:awtJNI_CreateColorData That's why in 1.2.2 creating X11GraphicsConfig is so fast. But if you call X11GC.getColorModel is still slow. awtJNI_CreateColorData has been moved to _init by Than during multiscreen changes (delta 1.23 of awt_GraphicsEnv.c). My suggestion is to move it back to _makeColorModel. It's risky as in this case we need to make sure that awt_cmap is initialized by the time we started to use it. I've tried to find where it's being used: - X11WindowSurfaceData: Our code calls X11GC.getColorModel from X11SurfaceData.createData(MComponentPeer), so awt_cmap will be initialized. - X11PixmapSurfaceData: we'll need to check awt_cmap before using it as we don't call getColorModel during it's creation (see changes in X11SurfaceData.c) - awt code (MComponentPeer.setBackground, setForeground etc) calls awtJNI_GetColorForVis or awtJNI_GetColor (setScrollbarBackground). So it's possible that getColorModel won't be called by the time one of these methods gets called. We can check awt_cmap in awtJNI_GetColorForVis (changes in color.c). - awt code using defalut configuration (by using getDefaultConfig) is OK: awt_initDisplay() calls makeDefaultConfig() for the default graphics configuration in awt_GraphicsEnv.c The fix will not affect ICM BufferedImages since they have their cmaps created in the different ways: - either in the BI constructor - or from BufImgSurfaceData.c BISD_Lock -> BufIng_SetupICM, so it's cmaps are initialized before they used. As for Win32, 1.4 a bit slower than in 1.2.2 because of the pixel formats which were introduced in 1.3. The worst case I've seen so far is on Win2K with 2 video boards (Voodoo 3 + Matrox Millenium): it takes about 3 seconds to call getConfigurations. That's because of Win32GraphicsDevice.isPixFmtSupported. It calls ::DescribePixelFormat which takes about 60 milliseconds per call. And we call it for each pixel format (about 36 of them on Win2K on my machine). On WinNT such a call takes just 40ms. But still, the sum of the time spent in getConfigurations and getColorModel is about the same for 1.4 and 1.2.x.. There is nothing we can do now to speed this up unless we change the overall approach: instead of returning all graphicsConfigurations and letting user select ones he needs we can allow user to specify his requirements and return GCs meeting those requirements. dmitri.trembovetski@eng 2000-09-21
21-09-2000
SUGGESTED FIX Defer color initalization to the time GraphicsConfiguration.getColorModel is called. Files affected: src/solaris/native/sun/awt/awt_GraphicsEnv.c src/solaris/native/sun/awt/color.c src/solaris/native/sun/awt/X11SurfaceData.c dmitri.trembovetski@eng 2000-09-21
21-09-2000