JDK-8311640 : Black color seen in Ensemble8 3D demos
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: internal
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2023-07-07
  • Updated: 2025-04-23
  • Resolved: 2025-04-23
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
internalFixed
Related Reports
Relates :  
JDK-8310658 - Add support for specular map in metal
Relates :  
JDK-8318985 - [macos] Incorrect 3D lighting on macOS 14 and later
Description
Regression is observed in Ensemble8 3D demos as compared to last month's run.
Please refer to the attached screenshots.

This is observed on macOS Ventura 13.2.1 on a x86_64 macBook with discrete graphics card.
Comments
We use 0 as default value for specular power when no specular color is set. And this 0 value is then used in pow() function which results in undefined behaviour. Similar issue is seen in OpenGL at https://bugs.openjdk.org/browse/JDK-8318985. When no specular color is set we need to use 32 as default value for specular power. This resolves the black color issue seen in Metal pipeline also.
23-04-2025
Patch is verified in aarch64 as well as x64 machines. Patch is also tested using Ensemble8 demo and fx83dfeatures
23-04-2025
Changeset: 421ef97a Branch: metal Author: Jayathirth Rao D V <jdv@openjdk.org> Date: 2025-04-23 17:57:06 +0000 URL: https://git.openjdk.org/jfx-sandbox/commit/421ef97a56689f0d2674caffd8305d9bc9b874f0
23-04-2025
Looks like even the "3DBox" anomaly that is captured in this bug behaves differently based on ISA. In my M1 aarch-64 machine, in Metal pipeline i see red-tinge but in case of OpenGL it is black. This behavior is invert of what we see in x64 macOS machine. Looks like root cause for "3DBox" issue also will be same as other black Ensemble8 issues captured here.
21-04-2025
This bug also causes a failure in one of our headful system tests: PointLightIlluminationTest > sphereLowerRightPixelColorShouldBeDarkRed() FAILED org.opentest4j.AssertionFailedError: expected:rgba(139,0,0,255) but was:rgba(0,0,0,255) PointLightIlluminationTest > sphereUpperRightPixelColorShouldBeDarkRed() FAILED org.opentest4j.AssertionFailedError: expected:rgba(139,0,0,255) but was:rgba(0,0,0,255) PointLightIlluminationTest > sphereUpperLeftPixelColorShouldBeDarkRed() FAILED org.opentest4j.AssertionFailedError: expected:rgba(139,0,0,255) but was:rgba(0,0,0,255) PointLightIlluminationTest > sphereLowerLeftPixelColorShouldBeDarkRed() FAILED org.opentest4j.AssertionFailedError: expected:rgba(139,0,0,255) but was:rgba(0,0,0,255) The above was on my MacBook Pro x64 system with a discrete graphics card. It was running macOS 15, but I doubt that matters.
06-02-2025
Thanks [~aghaisas] for sharing new 3D Box difference. I think this also might be specific to x86 as i see red tinge in both Metal and OpenGL for 3D Box in M1. Attached image for reference.
31-08-2023
This is still reproducible in the latest test run. Another observation is for "3D Box" demo that could be related - In ES2 the top and right side of the Box although appears black has a red tinge - RGB=(46,0,0) In metal, these two faces appear Black with RGB=(0,0,0) It might be an oversight in earlier testing due to the shadow appearing almost black.
31-08-2023
Made changes to not pass bool variable(Because this is reproducible only in x86 and padding can be an issue) in fragment shaders uniforms and use float4 vector only to pass all texture map related flags and shared the patch with Ambarish. Even with this patch issue is seen.
17-07-2023
This is not reproducible in M1 aarch64 Macbook Pro which is have. This is reproducible only on x64 machines. Also [~arapte] helped me to identify that this issue is happening after JDK-8310658 change.
10-07-2023