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

Tejesh R tr at openjdk.org
Fri Aug 30 07:23:19 UTC 2024


On Fri, 30 Aug 2024 07:15:42 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?

My bad, I misplaced `robot.createScreenCapture()` with `Robot.createMultiResolutionScreenCapture`.

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

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


More information about the client-libs-dev mailing list