JDK-8204931 : Colors with alpha are painted incorrectly on Linux
  • Type: Bug
  • Component: client-libs
  • Affected Version: 11
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_11
  • CPU: sparc
  • Submitted: 2018-06-08
  • Updated: 2021-11-19
  • Resolved: 2018-07-31
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
11 b25Fixed 12Fixed
Related Reports
Duplicate :  
JDK-8208072 - Colors with alpha are painted incorrectly on Linux
Relates :  
JDK-8275843 - Random crashes while the UI code is executed
Relates :  
JDK-8176795 - Wrong color drawn when painting translucent colors on volatile images using XRender.
Relates :  
JDK-8208072 - Colors with alpha are painted incorrectly on Linux
Relates :  
JDK-8214579 - JFrame does not paint content in XVFB / X11vnc environment
Relates :  
JDK-8227392 - Colors with alpha are painted incorrectly on Linux, after JDK-8214579
Relates :  
JDK-8275843 - Random crashes while the UI code is executed
Description
Testsuite name:JCK manual
Test name:api/java_awt/interactive/ColorTests.html#ColorTests
Product tested:JDK11b16(64bit)/JCK11b08
OS/architecture:Solaris 11.3 sparc 

Actual behavior:
The panel on the right does not display the color of the float alpha value indicated,please refer to ColorTest0004.jpg.

Affect Test:
ColorTest0003
Comments
URL: http://hg.openjdk.java.net/jdk/jdk11/rev/331888ea4a78 User: prr Date: 2018-07-31 21:05:01 +0000
31-07-2018
Fix request approved
31-07-2018
Fix Request: This is a TCK-RED bug where colors with alpha are no longer blended with the background. The fix and therefore any risk is confined to the Xrender pipeline, used on Linux and Solaris, and is a small change to store pixels for colors with alpha in pre-multiplied form, so it is further confined in effect to cases where alpha colors are used by the application. As well as the TCK test that failed, jtreg tests, all relevant automated JCK tests, and manual testing of SwingSet2 and J2Demo have been run to verify the fix. A new regression test is provided that passes on all platforms. The code has been reviewed by prasanta.sadhukhan@oracle.com and jayathirth.d.v@oracle.com Webrev : http://cr.openjdk.java.net/~prr/8204931/
27-07-2018
[~prr] Thanks for going through behavior of all types of XRSurfaceData and fixing the issue. Summary of Review: In JDK-8176795, we had volatile surface and whenever we called setColor() on this surface, internally XRender used PixelConverter and gave us Pre-Multiplied Color values. So there was no need for us to again convert these values in XRSolidSrcPict.prepareSrcPict(). So the change was made to disable conversion during renderng. Also this conversion is specific to SOLID src_types and there was no problem when we had TEXTURES/GRADIENT type. But when we are not using Volatile surface and source type is solid, we were using XRSolidSrcPict.prepareSrcPict() to convert non-pre color values to pre-color values. Because of this behavior we are seeing regression that is reported in this bug and JDK-8208072 after JDK-8176795. As part of http://cr.openjdk.java.net/~prr/8204931/, pixelConverter is added for IntRGB surface type in XRSurfaceData. This picks proper surface type with PixelConverter when we are calling createData() for XRPixmapSurfaceData. So this looks like fixes JDK-8208072, but for this bug as mentioned by Phil we need to override getSurfaceType() in XRGraphicsConfig so that we pick surfacetype with PixelConverter for XRWindowSurfaceData also.
27-07-2018
https://bugs.openjdk.java.net/browse/JDK-8176795 introduced this issue. The case there was that we had a volatile image with alpha, and we were storing the pixel for the color on the Graphics2D pre-multiplied, but the rendering code was treating it as non-premultiplied. The evaluation asserted that Xrender always wants pre-multiplied colors, so the code was updated to not re-apply this. And the site the code was changed, was the only case where the Xrender code would apply that pre-multiplication. Unfortunately, the case in this bug report, and in the duplicate report https://bugs.openjdk.java.net/browse/JDK-8208072 are cases where the surface is an X Pixmap or window and the PixelConverter which converted to pre-multiplied is not installed in this case. So the change in the previous fix broke what was needed to get the alpha blending expected here. The solution - based on the assertion XRender always expects colors premultiplied is to do that for the opaque pixmap too by installing the same PixelConverter. This is harmless when all colours involved are opaque. However whilst this fixed 8208072 it did not fix this bug because the Xrender pipeline was not installing the correct SurfaceType. It was using one for an X11 Surface, not an XR Surface, due to not over-riding getSurfaceType in XRGraphicConfig. So the pre-multiplying pixel converter was not picked up. Together these fixes do not regress the fix for JDK-8176795, and fix both the new issues. All automated jtreg+JCK for awt+swing pass. Also the JCK manual color tests - the ones that were reported to fail in this report - pass. The proposed fix http://cr.openjdk.java.net/~prr/8204931/ is limited to the XRender path so the risk is contained to the code that was having problems. There is however one change in behaviour when setting composite to AlphaComposite.SRC. As a result of storing the colours pre-multiplied Xrender now behaves the same as the D3D and OpenGL accelerated pipelines as described in this 5 year old thread : http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003757.html Previously it behaved as the software loops do, which is to copy the color as if it was solid / opaque. The discussion there ended without any follow-up fixes to make behaviour consistent, perhaps in part because although the accelerated pipelines' behaviour is reasonable, and the spec. is not very clear in this area. It was noted in the thread and again in https://bugs.openjdk.java.net/browse/JDK-5051225 that the ColorModel should really indicate it is pre-multiplied in this case, if only we could create such a ColorModel and that this would be fixed, but I can't see a bug about it. I did track down a couple of other bugs. The first seems to be describing the same as 5051225 https://bugs.openjdk.java.net/browse/JDK-6914138 The 2nd seems to have enshrined in the spec that for BI it will be non-premultiplied if it is opaque. https://bugs.openjdk.java.net/browse/JDK-4884869 Sorting out all of that is beyond this issue and changing the behaviour of BufferedImage could be a compatibility nightmare, even if the major accelerated pipelines disagree ..
26-07-2018
Test build:open JDK11 b22(64bit)/JCK11b11 Platform:oel7.4-uek-x64 Options: -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel The case failed as the same issue: api/java_awt/interactive/ColorTests_ColorTests
21-07-2018
Test build:openJDK11b20(64bit)/JCK11b10 Platform:oel7.4-uek-x64 Options:-Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel and Options: -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel The case failed as the same issue: RULE "api/java_awt/interactive/ColorTests_ColorTests" TestCase [ColorTest0003] Color test does NOT work as expected. Failed as JDK-8204931. Matches: RULE "api/java_awt/interactive/ColorTests_ColorTests" TestCase [ColorTest0004] Color test does NOT work as expected. Failed as JDK-8204931. Matches:
09-07-2018
Test build:JDK11b20(64bit)/JCK11b10 Platform:solaris11.3-sparc Options:-Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel The case failed as the same issue: RULE "api/java_awt/interactive/ColorTests_ColorTests" TestCase [ColorTest0003] Color test does NOT work as expected. Please refer to JDK-8204931. Matches: RULE "api/java_awt/interactive/ColorTests_ColorTests" TestCase [ColorTest0004] Color test does NOT work as expected. Please refer to JDK-8204931. Matches:
06-07-2018
This is not Solaris-specific. You'll find it fails on Linux too. It is specific to the Xrender pipeline and caused by this fix : https://bugs.openjdk.java.net/browse/JDK-8176795 -Dsun.java2d.xrender=false works around the problem.
13-06-2018