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

[Prasanta Sadhukhan]

Looks better. One more thing, out of these lines, only frame.paint() 
needs to be in EDT as it is a swing component but in your code, all code 
are running under EDT which is not needed.

113
114 // Capture the frame to an buffered image file as an ARGB file
115 bi = new BufferedImage(300 * (int)(tx.getScaleX()),
116 300 * (int)(tx.getScaleY()), BufferedImage.TYPE_INT_ARGB);
117
118 // Print the frame to buffered image
119 printToBufferedImage();
120 }
121
122 private static void printToBufferedImage() {
123 Graphics2D g2d = bi.createGraphics();
124
125 // Set to the new transform as set by HiDpi display units.
126 g2d.setTransform(tx);
127 g2d.drawImage(bi, null, null);
128
129 // paint the buffered image with the newly created frame
130 frame.paint(g2d);
131 g2d.dispose();
  132     }

Regards
Prasanta
On 6/6/2017 2:52 PM, Shashidhara Veerabhadraiah wrote:
> Hi, I have updated the Webrev with fixes for the comments @ http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_02/.
>
> Prasanth, I am not aware of the JBS id where this issue is going to be fixed.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Tuesday, June 6, 2017 1:15 PM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net; Sergey Bylokhov <sergey.bylokhov at oracle.com>
> Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193
>
> Do you know the JBS bugid of Robot's issue that is being resolved?
> I guess you need to call g2d.dispose() in printToBufferedImage() and can replace the wild card imports into specific imports. Also, take care of 80characters per line.
>
> Regards
> Prasa
> On 6/6/2017 12:04 PM, Shashidhara Veerabhadraiah wrote:
>> 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/20170606/e87be77d/attachment.html>