JDK-6304250 : XAWT: Items in choice show a blue border on OpenGL + Solaris10 when background color is set
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2005-07-30
  • Updated: 2019-01-17
  • Resolved: 2005-09-07
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.
JDK 6
6 b51Fixed
Related Reports
Relates :  
JDK-8214109 - XToolkit is not correctly displayed color on 16-bit high color setting
Relates :  
JDK-6304251 - OGL+XAWT: Items in the drop-down are offset after setting the Choice's font at run time
Relates :  
JDK-6322593 - OGL + XAWT: FileDialog drop-down is not properly painted when navigating thro' sub dirs
Description
I am setting the background color of a Choice to Color.red and running the application on Opengl pipeline by setting the flag -Dsun.java2d.opengl=True. When I click on Choice, the drop-down appears. 

1. A blue background is shown just before the drop-down appears. This will be well noticed when clicking on the choice many times repeatedly.

2. All the items in the choice show a blue border around them. This looks ugly. 

This happens only when background color is set to red. Not reproducible when background is not set. This is noticed on Tiger-FCS as well as Mustang-b44 with XToolkit, on SolarisSparc10, Sunblade-2500 having a XVR-600 frame buffer. Not reproducible on Win32.

I have attached a sample test to reproduce the test. I have also attached the platform information such as output of xdpyinfo and glxinfo.
Comments
SUGGESTED FIX *** /tmp/geta3792 Mon Aug 15 14:52:06 2005 --- XWindow.java Mon Aug 15 14:51:52 2005 *************** *** 21,26 **** --- 21,27 ---- import java.lang.reflect.*; import sun.java2d.SurfaceData; import sun.awt.PaintEventDispatcher; + import sun.awt.image.PixelConverter; public class XWindow extends XBaseWindow implements X11ComponentPeer { private static Logger log = Logger.getLogger("sun.awt.X11.XWindow"); *************** *** 379,389 **** // we call setBackground and we dont have all the stuff initialized to // do a full paint for most peers. So we cannot call setBackground in postInit. final public void xSetBackground(Color c) { - int pixel=0; try { XToolkit.awtLock(); winBackground(c); ! pixel = surfaceData.pixelFor(c.getRGB()); XlibWrapper.XSetWindowBackground(XToolkit.getDisplay(), getContentWindow(), pixel); } finally { --- 380,395 ---- // we call setBackground and we dont have all the stuff initialized to // do a full paint for most peers. So we cannot call setBackground in postInit. final public void xSetBackground(Color c) { try { XToolkit.awtLock(); winBackground(c); ! // Note: When OGL is enabled, surfaceData.pixelFor() will not ! // return a pixel value appropriate for passing to ! // XSetWindowBackground(). Therefore, we will use the ColorModel ! // for this component in order to calculate a pixel value from ! // the given RGB value. ! ColorModel cm = getColorModel(); ! int pixel = PixelConverter.instance.rgbToPixel(c.getRGB(), cm); XlibWrapper.XSetWindowBackground(XToolkit.getDisplay(), getContentWindow(), pixel); } finally {
15-08-2005
EVALUATION After further investigation I've found that the bug is in XAWT code, not in Sun's OGL libraries. I hacked the XChoicePeer and ListHelper code so that their paint() methods are empty (and therefore we are not using Java 2D to do any rendering). But even when I do this, the list background is blue when OGL is enabled. Therefore, this bug is likely in setting the background of the component. In XWindow.xSetBackground(), we currently have this line of code: int pixel = surfaceData.pixelFor(c.getRGB()); With the default X11-based pipeline, this code will work fine because surfaceData will be an X11(Window)SurfaceData, and the ColorModel for the surfaceData and the GraphicsConfig (visual) will be the same. But with the OGL-based pipeline enabled, surfaceData will be a GLX(Window)SurfaceData. Be aware that with OGLSurfaceData, it's a bit of a gray area as to the what the ColorModel of a window surface should be. If you call OGLSurfaceData.getGraphicsConfiguration(), you will get a GLXGraphicsConfig. And if you call GLXGraphicsConfig.getColorModel(), it is basically the same as calling X11GraphicsConfig.getColorModel(), so you will get the actual ColorModel for the screen/visual. However, if you're rendering to an OGLSurfaceData, that ColorModel doesn't really make sense. For the purposes of calculating an appropriate pixel value, we install an instance of PixelConverter.IntArgbPre for OGLSurfaceData. So anyway, getting back to the bug at hand... Imagine that the ColorModel for the visual is a DirectColorModel with a layout like IntBgr. With the X11 pipeline, if you call that line of code above with Color.red, the pixel value calculated by PixelConverter.Xbgr will be 0xff0000ff. This value means "red" when we pass this value to XSetWindowBackground(). Now try this same example with the OGL pipeline enabled. The pixel value in this case will be calculated by PixelConverter.IntArgbPre, so it will evaluate to 0xffff0000. When this value is passed to XSetWindowBackground(), it will be interpreted as blue, which is why we see blue when the OGL pipeline is enabled on a screen with an IntBgr layout. So how do we fix this? Well, I would suggest that in this case, since we are trying to calculate a pixel value for use with an Xlib call (XSetWindowBackground), XAWT code should not rely on surfaceData.pixelFor(). Yes, this will work with the X11 pipeline, but it will not work when OGL is enabled. Therefore, I suggest that we calculate the pixel value using the ColorModel of the target Component (which will be the same as the ColorModel of the GraphicsConfig). The easiest way to do this is to call: int pixel = PixelConverter.instance.rgbToPixel(c.getRGB(), cm); With this fix in place, this bug is no longer reproducible for either the X11 or OGL pipelines. I've updated the suggested fix, and will pass this back to the AWT team for consideration and putback.
15-08-2005
EVALUATION This bug is not reproducible on Linux with the latest Nvidia drivers, so it looks to be specific to Sun's OGL libraries. Therefore, it's not likely to be an AWT issue (or a 2D issue), but rather a bug in Sun's OGL drivers.
15-08-2005