On Mon, 9 Sep 2024 18:45:45 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? >> >> 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
