RFR: 8326027: [TEST_BUG]Comparing buffered images of white background frame fails in Mac

[Tejesh R]

On Mon, 9 Sep 2024 18:45:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > > Have you checked what is the root cause? Are the pixels drawn incorrectly in the frame, or is the robot distorting the colors when it grabs the pixels?
>>> > 
>>> > 
>>> > The issue occurs intermittently/might be even host specific. It occurs when Robot.createMultiResolutionScreenCapture is used to capture HiDPI image and comparing them. I believe it's related to Robot capture, rather than pixel drawn incorrectly since we haven't observed such case in headless test which actually compares colors using Graphics paint to buffered image.
>>> 
>>> I assume it's the opposite: if `Robot.createMultiResolutionScreenCapture` was used, the colours would be accurate (as displayed); whereas `Robot.createScreenCapture` scales down the screenshot which may introduce colour inaccuracy.
>>> 
>>> > > I wonder whether the tolerance wouldn't be required if `Robot.createMultiResolutionScreenCapture` was used to create the screenshot and then analysing the original image which didn't go through down-scaling in High DPI environment.
>>> > 
>>> > 
>>> > Yes, I have observed that some of the HiDPI image capture have this shades of pixels from expected which would require tolerance to be considered while comparing.
>>> 
>>> This is why I asked the question: does the comparison remain accurate without the need for tolerance if you use `Robot.createMultiResolutionScreenCapture` and use the highest resolution from the returned multi-resolution image?
>> 
>> I couldn't reproduce the issue neither with `Robot.createMultiResolutionScreenCapture` nor with `Robot.createScreenCapture` since the failure occurs intermittently, not able to say anything about using `Robot.createMultiResolutionScreenCapture` instead of  `Robot.createScreenCapture` .
>
>> > This is why I asked the question: does the comparison remain accurate without the need for tolerance if you use `Robot.createMultiResolutionScreenCapture` and use the highest resolution from the returned multi-resolution image?
>> 
>> I couldn't reproduce the issue neither with `Robot.createMultiResolutionScreenCapture` nor with `Robot.createScreenCapture` since the failure occurs intermittently, not able to say anything about using `Robot.createMultiResolutionScreenCapture` instead of `Robot.createScreenCapture` .
> 
> According to your report in JBS, the white color is not exactly white: `0xFFEE'EEEE`. White color has value of `0xFFFF'FFFF`.
> 
> However, it's also common on Macs (because of color profile applied?), I mean that the captured color value is the same as the value used for filling.
> 
> At the same time, I expect the color is the same across the entire frame surface. What we see is that there are variations. I wonder how many pixels on the image have different color, other than the first pixel.

@aivanov-jdk Any further comments/suggestions on this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2410158705