On Fri, 14 Nov 2025 06:20:08 GMT, Sergey Bylokhov <[email protected]> wrote:
>> 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?
Couple of observations
- The test fails irrespective of whether opengl or metal pipeline is used
- The color inconsistency is not only at the edges but at random points (can be
checked by enabling DEBUG in the test)
- Apple introduced Metal 4 APIs on Apple macOS26 but this can be eliminated as
the root cause since the issue occurs on macOS26 x64 as well and when using
opengl.
- Setting color profile to sRGB doesn't work either.
- One probable cause could be that CRobot uses deprecated
[CGWindowListCreateImage](https://developer.apple.com/documentation/coregraphics/cgwindowlistcreateimage(_:_:_:_:)?language=objc)
for screencapture and the recommended new API is ScreenCaptureKit.
Currently the test fails on CI (macOS26) creating noise and adding a color
tolerance is the best workaround for now until the root cause or the new
feature/setting which is causing the issue on macOS26 is found. I'll create a
new JBS issue to track it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28312#discussion_r2529204369
