On Fri, 30 Aug 2024 04:59:58 GMT, Tejesh R <t...@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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2320305136
