RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26

[Sergey Bylokhov]

On Thu, 13 Nov 2025 23:24:07 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This test started to fail on macOS26 due to color inconsistency at certain points.
>> Color tolerance has been added as a fix.
>> 
>> The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta /PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta / TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color.
>> 
>> Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one.
>>  
>> Tested locally on macOS 26.0.1 and 26.1 and fix works as expected.
>> 
>> CI testing on other platforms looks good and no regressions are observed (Link added to JBS).
>
> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 73:
> 
>> 71:         try {
>> 72:             if (!Platform.isOSX()) {
>> 73:                 TOLERANCE = PRIMARY_TOLERANCE;
> 
> I could set tolerance and primary_tolerance both to zero on other platforms although I have currently set it to a small delta of 2. I can change it to zero if any reviewers suggest that exact color compare would be better.

What is the reason for the color mismatch? Is it possible to check whether it is caused by the rendering pipeline (for example, different colors between metal and ogl), by the native code used by robot (we could compare it with a native screencapture tool), by the code that converts the native image to Java (using Robot.createMultiResolutionScreenCapture might help), or by some blending at the edges of the rendered area?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28312#discussion_r2525923170