I checked with isEventDispatchThread() java api on the program and found that
it is not running on EDT but running on the initial thread!! Is it really
required to run the frame paint on the EDT as it is not a responsive
GUI(non-event based) but an automatic test case to capture the image onto a
Hi Sergey,
Why do we omitting closing th tag?
e.g.
+ * Metal's system color mapping
+ *
+ *
+ * Key
+ * Value
+ *
I know that HTML parsers are usually forgiving such things. But
sometimes it may make thing worse:
https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of
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)(
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
Please find the modified webrev incorporating your review comment
http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/
Regards
Prasanta
On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
- There is a problem in your algorithm which merges the old and new clips.
The getClipBounds() returns a r
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 Veerabhadra
