On Fri, 30 Aug 2024 07:15:42 GMT, Alexey Ivanov <aiva...@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? My bad, I misplaced `robot.createScreenCapture()` with `Robot.createMultiResolutionScreenCapture`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2320316643
