JDK-8214109 : XToolkit is not correctly displayed color on 16-bit high color setting
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u192,11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-11-20
  • Updated: 2019-09-26
  • Resolved: 2019-02-26
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 11 JDK 12 JDK 13 JDK 8 Other
11.0.4-oracleFixed 12.0.2Fixed 13 b14Fixed 8u221Fixed openjdk8u222Fixed
Related Reports
Relates :  
JDK-6304250 - XAWT: Items in choice show a blue border on OpenGL + Solaris10 when background color is set
Description
While using 16-bit high color（R:5bit, G:6bit, B:5bit）graphics 
due to resource limitation, the background color of panel is specified as 
light gray, but the color of repaint area is not drawn by that color. In the 
case of background color setting, the value generated by 
sun.awt.image.PixelConverter class is used. However, when rendering like 
repaint, the value of Ushort565Rgb class which is an inner class of 
PixelConverter is used. Due to this difference in the values used, colors do 
not match. 
The difference between the two values is as follows: 
    java.awt.image.ColorModel cm = new 
java.awt.image.DirectColorModel(16,0xf800,0x7e0,0x1f); 
    ... 
    A = 
sun.awt.image.PixelConverter.instance.rgbToPixel(java.awt.Color.lightGray,cm); 
 // value of background color 
    B = 
sun.awt.image.PixelConverter.Ushort565Rgb.instance.rgbToPixel(java.awt.Color.l 
ightGray,cm); //value of repaint color 

    A -> #bdf7：10111 101111 10111 
    B -> #c618：11000 110000 11000 
    java.awt.Color.lightGray = #c0c0c0：11000000 11000000 11000000 

Each one is getting the correct value. 0xbdf7 is set as the background color 
of window and 0xc618 is set to the drawing color of fillRect() called by 
repaint. Therefore, when part of the Panel is redrawn, the phenomenon occurs 
that only the area is different in color.
Comments
Fix Request (12u) This request follows the completed backports to 11u and 8u. Patch applies cleanly to 12u. VNC-based test (as described above) works fine after the patch, and looks wrong before the patch. The risk is minimal.
01-04-2019
Fix Request This issue solves GTK 3+ compatibility problem. Patch applies cleanly to 11u (and I see 11.0.4-oracle), and to 8u with reshuffling (and I see 8u221/222). VNC-based test (as described above) works fine after the patch, and looks wrong before the patch. The risk is minimal.
19-03-2019
Problem description: On xvnc4 environment the colour of the background and the colour of the repaint area may be different (and it���s visually noticeable) even if the same colour is specified. The root cause of this behaviour is that we always use ColorModel to calculate a pixel value in XWindow.xSetBackground() and at the same time the pixel value for repaint area is calculated using SurfaceData methods, (e.g. SurfaceData.pixelFor()). Actually this is regression caused by JDK-6304250 which introduced ColorModel based calculation of the pixel value to fix problem for OpenGL pipeline. Proposed fix: It is necessary to modify XWindow.xSetBackground(): if OpenGL pipeline is enabled we should use ColorModel to calculate the pixel value; otherwise we should use SurfaceData.pixelFor() for calculation.
17-01-2019
The problem is reproducible on jdk8, 11, 12 and 13
17-01-2019
The issue is reproducible when xvnc4 is used but it does not take place if x11vnc is used. The difference I found so far is that XRender pipeline cannot be enabled when xvnc4 is used. I get the following message when I try enable XRender on xvnc4, (i.e. java -Dsun.java2d.xrender=True ColorSurvey): ���Could not enable XRender pipeline���. Also the problem happens in x11vnc environment if XRender pipeline is disabled, (i.e. java -Dsun.java2d.xrender=false ColorSurvey). Possible workaround: use x11vnc with enabled XRender pipeline.
17-01-2019
I can reproduce the problem on Ubuntu using ColorSurvey.java from the attachment. I use the vnc4server and gvncviewer. Steps to reproduce: 1. Start vnc server, (i.e. vncserver :18 -depth 16 &) 2. Start vnc client, (i.e. gvncviewer localhost:18 &) 3. Run ColorSurvey.java from the client, (i.e. java ColorSurvey) Actual result: Observe behaviour as shown at the left part (CentOS 6) of the screenshot.png (see attachment) Expected result: Observe behaviour as shown at the right part (CentOS 7) of the screenshot.png (see attachment)
17-01-2019