<Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Wed Jul 5 05:32:06 UTC 2017

Hi All, Since JDK 9 is closed, am targeting this Webrev to JDK 10. Since below test only review has been performed and accepted for JDK 9, am proposing to use the same and target to JDK10 with the following webrev.

http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_05/

Thanks and regards,

Shashi

From: Sergey Bylokhov 
Sent: Monday, July 3, 2017 11:44 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: swing-dev at openjdk.java.net; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Looks fine.

----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: 
> 

> 

> 

Hi Sergey, Thank you for the comments. Here is the updated Webrev for the comment fixes:

http://cr.openjdk.java.net/~aghaisas/shashi/8165213/webrev_04/

Thanks and regards,

Shashi

> 

From: Sergey Bylokhov 
> Sent: Thursday, June 22, 2017 8:22 PM
> To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
> Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>
> Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Hi, Shashi.

Please do not use the empty catch blocks, always rethrow an exception.

Note that you need to check the count of images returned by getResolutionVariants(), it will be one image on non-hopi screen. It seems that the «images;» field may be local in testGradient() method.

Hi Sergey, I have uploaded test per our discussion and is available at:

http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_03/

Please review and do provide the comments if any.

Thanks and regards,

Shashi

> 

From: Shashidhara Veerabhadraiah 
> Sent: Thursday, June 15, 2017 2:40 PM
> To: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>
> Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>
> Subject: RE: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Hi Sergey,  The color profile on mac was generic RGB. Moreover the robot api takes the co-ordinates as input as against my implementation which takes the component as input and hence we always get the exact component image onto the buffered image. The component’s coordinates may vary depending on the location of the task bar like on mac or linux(ubuntu), hence the supplied co-ordinates may go awry. I feel that capturing the component directly onto the buffered image is better considering the cross platforms. Please let me know if you feel otherwise.

Below is the image comparison between the windows(top) and linux(below), snapshot that was captured onto the buffered image as a png file. I see that the linux component is slightly bigger by around 4 pixel width(approx.). I think this is the reason behind the color differences across the platforms and the same reason why mac has color differences at the same location when compared with windows one. Same location means that the program supplies a size of 300 * 300 width component and the location where we extract the color is calculated automatically based on the component size.

<image002.jpg>

I am not sure why there is a change in width. I am not sure should I continue to debug in that direction or not!!

This is the logical explanation that I could achieve for the color tolerance band that was used in the program. So please let me know what do you think of this.

Thanks and regards,

Shashi

-----Original Message-----
> From: Sergey Bylokhov 
> Sent: Thursday, June 8, 2017 1:12 PM
> To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
> Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>
> Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

On what color profiles the test is executed? On macOS it should be Generic RGB. Also in jdk9 the new robot api for HiDPI was added, please try it also.

If it solve the problem on Mac then I suggest to try to investigate a problem on Linux and fix it if possible, instead of tweaking the test.

> 

> Hi All,

>             Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.

> 

> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.

> 

> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.

> Based on the test outputs, the tolerance band for color comparison is set at 11.

> 

> Test outputs: 

> 1. On a windows system, the pixel color values exactly matches.

> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.

> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.

> 

> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213

> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/

> 

> Thanks and regards,

> Shashi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170704/19bd0c25/attachment.html>