On Thu, 13 Nov 2025 23:24:07 GMT, Harshitha Onkar <[email protected]> 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
