SUGGESTED FIX

*** /tmp/geta7379	Thu Oct 20 11:03:38 2005
--- awt_GraphicsEnv.c	Thu Oct 20 10:58:11 2005
***************
*** 252,257 ****
--- 252,259 ----
      xinawareScreen = usingXinerama ? 0 : screen;
      defaultVisualID = 
  	XVisualIDFromVisual(DefaultVisual(awt_display, xinawareScreen));
+ 
+     memset(&vinfo, 0, sizeof(XVisualInfo));
      vinfo.screen = xinawareScreen;
  
      if ((forcedVisualStr = getenv("FORCEDEFVIS"))) {
***************
*** 284,298 ****
      if (defaultConfig) {
  	return defaultConfig;
      }
!     
!     /* try the default visual if we haven't already */
!     if (vinfo.visualid != defaultVisualID) {
! 	vinfo.visualid = defaultVisualID;
! 	mask = VisualIDMask | VisualScreenMask;
! 	defaultConfig = findWithTemplate(&vinfo, mask);
! 	if (defaultConfig) {
! 	    return defaultConfig;
! 	}
      }
  
      /* try any TrueColor */
--- 286,298 ----
      if (defaultConfig) {
  	return defaultConfig;
      }
! 
!     /* try the default visual */
!     vinfo.visualid = defaultVisualID;
!     mask = VisualIDMask | VisualScreenMask;
!     defaultConfig = findWithTemplate(&vinfo, mask);
!     if (defaultConfig) {
!         return defaultConfig;
      }
  
      /* try any TrueColor */
                                     

EVALUATION

Here's what causes us to choose a weird visual.

Here's how awt_GraphicsEnv.c' makeDefaultConfig() is supposed to work:
  if a specific visual is forced, try using it
  else first try 24-bit TrueColor visual
  if didn't succeed, try the screen's default visual
  if didn't succeed, try other visual classes

In this case all visuals are 8-bit, so we first fail to 
find a 24-bit visual, and are supposed to try a default visual,
which should've had succeded.

But before trying the default visual, we first check that we haven't tried it 
already (like if it was forced, for example):
if (vinfo.visualid != defaultVisualID) {
    vinfo.visualid = defaultVisualID;
    mask = VisualIDMask | VisualScreenMask;
    defaultConfig = findWithTemplate(&vinfo, mask);
    return defaultConfig;
}

The problem is that prior to this line vinfo.visualid hasn't been 
initialized. So if by a weird coincidence the uninizialized vinfo.visualid 
is equal to the default visual id, we would assume that we've already
tried the default visual and failed, so we proceed to trying the next
visual class in line, which happens to be TrueColor class. Since there's
a TrueColor 8-bit visual, we pick it.

Interestingly, this actually happens: the uninitialized field does
equal to the default visual id, but only in an optimized jdk.
I can't reproduce the bug with 1.4.2_05 with the debug build:
there vinfo.visuaid field contains some garbage, so the check fails
and we use the default visual as we were supposed to.

It's possible that the linker patch somehow affected the memory used
for the vinfo structure, making this bug more probable.

Anyway, if the vinfo structure is cleared prior to being used, the
bug goes away. I'm not sure what initial valueis guaranteed not to ever
be equal to the default visual id, so it's best to just use different
means of checking that we'd already tried the default config, or
just try it again anyway.

Note that even though this bug doesn't currently manifest in Mustang, we 
need to fix it there anyway, as it's just plain luck.
                                     

EVALUATION

I still doubt that the problem is caused by the patch. I have a Solaris 8 system which
has -32 revision of this patch and yet I can reproduce the problem.

Which appears to be caused by the fix for 
  4639878: Java2D does not support 12 bit depth visuals

In this fix we've changed the way a default visual is selected.
Unfortunately in case when there are only 8 bit visuals it now
choses a TrueColor 8-bit visual instead of the default PseudoColor 
visual.
On some video boards this causes desktop/application flashing.
                                     

WORK AROUND

Force the default visual by setting FORCEDEFVIS env. variable prior
to starting java application:
  FORCEDEFVIS=true    // force the default X server visual to be used by java
or
  FORCEDEFVIS=vis_num // force the use of visual vis_num as the default java's
	              // visual (you can get the desired visual number using xdpyinfo)
                                     

EVALUATION

109147 is a Solaris linker patch -  I find it very hard to see the connection.

Patch Id: 109147-37
Summary: SunOS 5.8: linker patch

Is that the correct patch number?
Is this reproducible with JDK 1.5 or later?
requesting verification on both of these points.

Hi,
For point (1):
Yes, it is correct patch number. I did MANY tests with and without patch 109147-34. IT IS THE CORRECT PATCH ID. YES , IT IS. I was surprised too. 
For point (2):
As you request, I just tried Java 1.5.0_06, the problem is still there. This problem only shows up with 1.4.2_5 or later with patch 109147-34. If you use older java, or no 109147-34, there is no problem. This problem happens on PGX24, PGX32 and PGX64, namely it is very framebuffer independent, since PGX32 is 3rd party cards, it is a totally different animal comparing with PGX24 and PGX64. The wilder guess I have is that Jave2D is using its owner colormap, and the process it is loading its own colormap related to the linker.

Luke