From Sergey.Bylokhov at oracle.com  Mon Mar  3 11:48:32 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 03 Mar 2014 23:48:32 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <530DFCE6.2020508@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com>
Message-ID: <5314DC90.4030509@oracle.com>

Hi, Alexander.
nativeGetNSImageRepresentationsCount three times return different values 
in case of error (0, NULL, nil).
What exception we expect from the SetObjectArrayElement and why we 
continue in this case?
Also please split soooooooooooooo long lines in these files.

On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>
>  Hello,
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>
> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>>
>> I have a couple of comments:
>>
>> 1. You could replace the first loop with indexOfObjectPassingTest 
>> method.. Not sure if this would look cleaner, up to you.
>     Updated. There is one more way to use one loop instead of two. All 
> of them does not look simple.
>
>>   2. I suppose JNFNewObjectArray could throw the OOM and we would get 
>> a parfait warning, could you please add CHECK_NULL_RETURN after it.
>     CHECK_NULL_RETURN is added.
>> 3. In CImage.java you are setting the currentImageIndex to the 
>> biggest image representation smaller that the one requested and this 
>> representation
>> would be used as a base one in the MultiResolutionBufferedImage. 
>> However in MultiResolutionBufferedImage getResolutionVariant you are 
>> returning
>> the smallest variant bigger than the requested one. Is this correct?
>     I think that it is correct. Assume that an image with size 300x300 
> is requested but there are only resolution variants with sizes 
> [250x250] and [350x350].
>     The resolution variant with  [350x350] size is used as the base 
> image.  Now we need to draw the image to region [300x300]. The 
> resolution variant
>     with size [350x350] will be used from the MultiResolution image.
>
>   Thanks,
>   Alexandr.
>
>
>>
>> Thank you.
>> With best regards. Petr.
>>
>> On 26.02.2014, at 16:08, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com> wrote:
>>
>>>   Hello,
>>>
>>>   Could you review the updated fix:
>>>       http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>
>>>   This is the same fix. The only difference is that the 
>>> MultiResolutionBufferedImage class is used from the fix JDK-8035069.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>> Just to be clear, "the image representations are chosen to be 
>>>> closest to the requested size" is not accurate.
>>>> This change returns the smallest image representation that is 
>>>> greater than or equal to the requested size.  (Which I believe is 
>>>> the correct thing to do.)
>>>> A smaller image representation may be closer to the requested size, 
>>>> but it makes more sense to return a larger image since scaling down 
>>>> to size should produce better results than scaling up.
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com 
>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>
>>>>
>>>>     Could you review the updated fix:
>>>>     http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>
>>>>      - The image representations are chosen to be closest to the
>>>>     requested size.
>>>>
>>>>       Thanks,
>>>>       Alexandr.
>>>>
>>>>
>>>>     On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>
>>>>         Hi, Alexander.
>>>>         I think that getResolutionVariant should return an image which
>>>>         is close as much as possible to the requested size.
>>>>
>>>>         On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>
>>>>
>>>>             Hello,
>>>>
>>>>             Could you review the fix:
>>>>               bug: https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>               webrev:
>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>
>>>>             - The method that gets a sorted array of NSImage
>>>>             representaion pixel sizes for the given image size is 
>>>> added
>>>>             - A MultiResolution image is created if an NSImage has
>>>>             several representations for the given image size
>>>>
>>>>             Thanks,
>>>>             Alexandr.
>>>>
>>>>
>>>>
>>>>
>>>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Mar  4 03:04:55 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 04 Mar 2014 15:04:55 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <5314DC90.4030509@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
Message-ID: <5315B357.5030901@oracle.com>


   Hello,

  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8033534/webrev.04

   - NULL is returned for all cases from the 
nativeGetNSImageRepresentationsCount method
   - long lines are split
   - SetObjectArrayElement can throw ArrayIndexOutOfBoundsException and 
ArrayStoreException exceptions.
     We do not expect neither of them because the same length and type 
is used for the array creation and element settings.
     I updated the exception handling to return NULL if an exception occurs.

   Thanks,
   Alexandr.


On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> nativeGetNSImageRepresentationsCount three times return different 
> values in case of error (0, NULL, nil).
> What exception we expect from the SetObjectArrayElement and why we 
> continue in this case?
> Also please split soooooooooooooo long lines in these files.
>
> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>
>>  Hello,
>>
>>   Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>
>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> I have a couple of comments:
>>>
>>> 1. You could replace the first loop with indexOfObjectPassingTest 
>>> method.. Not sure if this would look cleaner, up to you.
>>     Updated. There is one more way to use one loop instead of two. 
>> All of them does not look simple.
>>
>>>   2. I suppose JNFNewObjectArray could throw the OOM and we would 
>>> get a parfait warning, could you please add CHECK_NULL_RETURN after it.
>>     CHECK_NULL_RETURN is added.
>>> 3. In CImage.java you are setting the currentImageIndex to the 
>>> biggest image representation smaller that the one requested and this 
>>> representation
>>> would be used as a base one in the MultiResolutionBufferedImage. 
>>> However in MultiResolutionBufferedImage getResolutionVariant you are 
>>> returning
>>> the smallest variant bigger than the requested one. Is this correct?
>>     I think that it is correct. Assume that an image with size 
>> 300x300 is requested but there are only resolution variants with 
>> sizes [250x250] and [350x350].
>>     The resolution variant with  [350x350] size is used as the base 
>> image.  Now we need to draw the image to region [300x300]. The 
>> resolution variant
>>     with size [350x350] will be used from the MultiResolution image.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 26.02.2014, at 16:08, Alexander Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>>   Hello,
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>
>>>>   This is the same fix. The only difference is that the 
>>>> MultiResolutionBufferedImage class is used from the fix JDK-8035069.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>
>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>> Just to be clear, "the image representations are chosen to be 
>>>>> closest to the requested size" is not accurate.
>>>>> This change returns the smallest image representation that is 
>>>>> greater than or equal to the requested size.  (Which I believe is 
>>>>> the correct thing to do.)
>>>>> A smaller image representation may be closer to the requested 
>>>>> size, but it makes more sense to return a larger image since 
>>>>> scaling down to size should produce better results than scaling up.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy 
>>>>> <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>
>>>>>
>>>>>     Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>
>>>>>      - The image representations are chosen to be closest to the
>>>>>     requested size.
>>>>>
>>>>>       Thanks,
>>>>>       Alexandr.
>>>>>
>>>>>
>>>>>     On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>
>>>>>         Hi, Alexander.
>>>>>         I think that getResolutionVariant should return an image 
>>>>> which
>>>>>         is close as much as possible to the requested size.
>>>>>
>>>>>         On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>
>>>>>
>>>>>             Hello,
>>>>>
>>>>>             Could you review the fix:
>>>>>               bug: https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>               webrev:
>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>
>>>>>             - The method that gets a sorted array of NSImage
>>>>>             representaion pixel sizes for the given image size is 
>>>>> added
>>>>>             - A MultiResolution image is created if an NSImage has
>>>>>             several representations for the given image size
>>>>>
>>>>>             Thanks,
>>>>>             Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>
>
> -- 
> Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Mar  4 03:30:21 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 4 Mar 2014 15:30:21 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <5315B357.5030901@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
	<5315B357.5030901@oracle.com>
Message-ID: <A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>

Hello, Alexander.

In CImage.m:430 - Do we really want to describe and clear the exception? 
May be it's better to simply return NULL and let Java handle the exception?
This made sense when you were continuing the loop, but now doesn't.

With best regards. Petr.

On 04.03.2014, at 15:04, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
>  Hello,
> 
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8033534/webrev.04
> 
>  - NULL is returned for all cases from the nativeGetNSImageRepresentationsCount method
>  - long lines are split
>  - SetObjectArrayElement can throw ArrayIndexOutOfBoundsException and ArrayStoreException exceptions.
>    We do not expect neither of them because the same length and type is used for the array creation and element settings.
>    I updated the exception handling to return NULL if an exception occurs.
> 
>  Thanks,
>  Alexandr.
> 
> 
> On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> nativeGetNSImageRepresentationsCount three times return different values in case of error (0, NULL, nil).
>> What exception we expect from the SetObjectArrayElement and why we continue in this case?
>> Also please split soooooooooooooo long lines in these files.
>> 
>> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>> 
>>> Hello,
>>> 
>>>  Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>> 
>>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>> 
>>>> I have a couple of comments:
>>>> 
>>>> 1. You could replace the first loop with indexOfObjectPassingTest method.. Not sure if this would look cleaner, up to you.
>>>    Updated. There is one more way to use one loop instead of two. All of them does not look simple.
>>> 
>>>>  2. I suppose JNFNewObjectArray could throw the OOM and we would get a parfait warning, could you please add CHECK_NULL_RETURN after it.
>>>    CHECK_NULL_RETURN is added.
>>>> 3. In CImage.java you are setting the currentImageIndex to the biggest image representation smaller that the one requested and this representation
>>>> would be used as a base one in the MultiResolutionBufferedImage. However in MultiResolutionBufferedImage getResolutionVariant you are returning
>>>> the smallest variant bigger than the requested one. Is this correct?
>>>    I think that it is correct. Assume that an image with size 300x300 is requested but there are only resolution variants with sizes [250x250] and [350x350].
>>>    The resolution variant with  [350x350] size is used as the base image.  Now we need to draw the image to region [300x300]. The resolution variant
>>>    with size [350x350] will be used from the MultiResolution image.
>>> 
>>>  Thanks,
>>>  Alexandr.
>>> 
>>> 
>>>> 
>>>> Thank you.
>>>> With best regards. Petr.
>>>> 
>>>> On 26.02.2014, at 16:08, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>> 
>>>>>  Hello,
>>>>> 
>>>>>  Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>> 
>>>>>  This is the same fix. The only difference is that the MultiResolutionBufferedImage class is used from the fix JDK-8035069.
>>>>> 
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>> 
>>>>> 
>>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>>> Just to be clear, "the image representations are chosen to be closest to the requested size" is not accurate.
>>>>>> This change returns the smallest image representation that is greater than or equal to the requested size.  (Which I believe is the correct thing to do.)
>>>>>> A smaller image representation may be closer to the requested size, but it makes more sense to return a larger image since scaling down to size should produce better results than scaling up.
>>>>>> 
>>>>>> Scott
>>>>>> 
>>>>>> 
>>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>>    Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>> 
>>>>>>     - The image representations are chosen to be closest to the
>>>>>>    requested size.
>>>>>> 
>>>>>>      Thanks,
>>>>>>      Alexandr.
>>>>>> 
>>>>>> 
>>>>>>    On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>> 
>>>>>>        Hi, Alexander.
>>>>>>        I think that getResolutionVariant should return an image which
>>>>>>        is close as much as possible to the requested size.
>>>>>> 
>>>>>>        On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>> 
>>>>>> 
>>>>>>            Hello,
>>>>>> 
>>>>>>            Could you review the fix:
>>>>>>              bug: https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>>              webrev:
>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>> 
>>>>>>            - The method that gets a sorted array of NSImage
>>>>>>            representaion pixel sizes for the given image size is added
>>>>>>            - A MultiResolution image is created if an NSImage has
>>>>>>            several representations for the given image size
>>>>>> 
>>>>>>            Thanks,
>>>>>>            Alexandr.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 


From alexandr.scherbatiy at oracle.com  Tue Mar  4 03:39:58 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 04 Mar 2014 15:39:58 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
	<5315B357.5030901@oracle.com>
	<A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>
Message-ID: <5315BB8E.1030400@oracle.com>

On 3/4/2014 3:30 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> In CImage.m:430 - Do we really want to describe and clear the exception?
> May be it's better to simply return NULL and let Java handle the exception?
> This made sense when you were continuing the loop, but now doesn't.
    The exception is cleared because it should not be thrown on the Java 
side.
    For example the 
Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") call
    should not throw an exception in case if 
nativeGetNSImageRepresentationSizes() call fails.
    It should just return an Image without resolution variants.
    The ExceptionDescribe is left just for debugging purposes.

   Thanks,
   Alexandr.

>
> With best regards. Petr.
>
> On 04.03.2014, at 15:04, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>>   Hello,
>>
>> Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8033534/webrev.04
>>
>>   - NULL is returned for all cases from the nativeGetNSImageRepresentationsCount method
>>   - long lines are split
>>   - SetObjectArrayElement can throw ArrayIndexOutOfBoundsException and ArrayStoreException exceptions.
>>     We do not expect neither of them because the same length and type is used for the array creation and element settings.
>>     I updated the exception handling to return NULL if an exception occurs.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> nativeGetNSImageRepresentationsCount three times return different values in case of error (0, NULL, nil).
>>> What exception we expect from the SetObjectArrayElement and why we continue in this case?
>>> Also please split soooooooooooooo long lines in these files.
>>>
>>> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>>> Hello,
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>>>
>>>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>>>> Hello, Alexander.
>>>>>
>>>>> I have a couple of comments:
>>>>>
>>>>> 1. You could replace the first loop with indexOfObjectPassingTest method.. Not sure if this would look cleaner, up to you.
>>>>     Updated. There is one more way to use one loop instead of two. All of them does not look simple.
>>>>
>>>>>   2. I suppose JNFNewObjectArray could throw the OOM and we would get a parfait warning, could you please add CHECK_NULL_RETURN after it.
>>>>     CHECK_NULL_RETURN is added.
>>>>> 3. In CImage.java you are setting the currentImageIndex to the biggest image representation smaller that the one requested and this representation
>>>>> would be used as a base one in the MultiResolutionBufferedImage. However in MultiResolutionBufferedImage getResolutionVariant you are returning
>>>>> the smallest variant bigger than the requested one. Is this correct?
>>>>     I think that it is correct. Assume that an image with size 300x300 is requested but there are only resolution variants with sizes [250x250] and [350x350].
>>>>     The resolution variant with  [350x350] size is used as the base image.  Now we need to draw the image to region [300x300]. The resolution variant
>>>>     with size [350x350] will be used from the MultiResolution image.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 26.02.2014, at 16:08, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>>>
>>>>>>   Hello,
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>>>
>>>>>>   This is the same fix. The only difference is that the MultiResolutionBufferedImage class is used from the fix JDK-8035069.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>
>>>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>>>> Just to be clear, "the image representations are chosen to be closest to the requested size" is not accurate.
>>>>>>> This change returns the smallest image representation that is greater than or equal to the requested size.  (Which I believe is the correct thing to do.)
>>>>>>> A smaller image representation may be closer to the requested size, but it makes more sense to return a larger image since scaling down to size should produce better results than scaling up.
>>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>     Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>>>
>>>>>>>      - The image representations are chosen to be closest to the
>>>>>>>     requested size.
>>>>>>>
>>>>>>>       Thanks,
>>>>>>>       Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>     On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>>>
>>>>>>>         Hi, Alexander.
>>>>>>>         I think that getResolutionVariant should return an image which
>>>>>>>         is close as much as possible to the requested size.
>>>>>>>
>>>>>>>         On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>>             Hello,
>>>>>>>
>>>>>>>             Could you review the fix:
>>>>>>>               bug: https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>>>               webrev:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>>>
>>>>>>>             - The method that gets a sorted array of NSImage
>>>>>>>             representaion pixel sizes for the given image size is added
>>>>>>>             - A MultiResolution image is created if an NSImage has
>>>>>>>             several representations for the given image size
>>>>>>>
>>>>>>>             Thanks,
>>>>>>>             Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>> -- 
>>> Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Mar  4 03:53:28 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 4 Mar 2014 15:53:28 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <5315BB8E.1030400@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
	<5315B357.5030901@oracle.com>
	<A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>
	<5315BB8E.1030400@oracle.com>
Message-ID: <0C035A2D-21C9-4DA0-8054-7156A42E7F3C@oracle.com>

I'm fine with the fix.

>> Hello, Alexander.
>> 
>> In CImage.m:430 - Do we really want to describe and clear the exception?
>> May be it's better to simply return NULL and let Java handle the exception?
>> This made sense when you were continuing the loop, but now doesn't.
>   The exception is cleared because it should not be thrown on the Java side.
>   For example the Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") call
>   should not throw an exception in case if nativeGetNSImageRepresentationSizes() call fails.
>   It should just return an Image without resolution variants.
>   The ExceptionDescribe is left just for debugging purposes.
In real life this will never happen, so I'm fine with any decision) 
Just CHECK_EXCEPTION_RETUEN looks nicer than these 3 lines.

With best regards. Petr.

On 04.03.2014, at 15:39, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> On 3/4/2014 3:30 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> In CImage.m:430 - Do we really want to describe and clear the exception?
>> May be it's better to simply return NULL and let Java handle the exception?
>> This made sense when you were continuing the loop, but now doesn't.
>   The exception is cleared because it should not be thrown on the Java side.
>   For example the Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") call
>   should not throw an exception in case if nativeGetNSImageRepresentationSizes() call fails.
>   It should just return an Image without resolution variants.
>   The ExceptionDescribe is left just for debugging purposes.
> 
>  Thanks,
>  Alexandr.
> 
>> 
>> With best regards. Petr.
>> 
>> On 04.03.2014, at 15:04, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>> 
>>>  Hello,
>>> 
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8033534/webrev.04
>>> 
>>>  - NULL is returned for all cases from the nativeGetNSImageRepresentationsCount method
>>>  - long lines are split
>>>  - SetObjectArrayElement can throw ArrayIndexOutOfBoundsException and ArrayStoreException exceptions.
>>>    We do not expect neither of them because the same length and type is used for the array creation and element settings.
>>>    I updated the exception handling to return NULL if an exception occurs.
>>> 
>>>  Thanks,
>>>  Alexandr.
>>> 
>>> 
>>> On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> nativeGetNSImageRepresentationsCount three times return different values in case of error (0, NULL, nil).
>>>> What exception we expect from the SetObjectArrayElement and why we continue in this case?
>>>> Also please split soooooooooooooo long lines in these files.
>>>> 
>>>> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>>>> Hello,
>>>>> 
>>>>>  Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>>>> 
>>>>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>>>>> Hello, Alexander.
>>>>>> 
>>>>>> I have a couple of comments:
>>>>>> 
>>>>>> 1. You could replace the first loop with indexOfObjectPassingTest method.. Not sure if this would look cleaner, up to you.
>>>>>    Updated. There is one more way to use one loop instead of two. All of them does not look simple.
>>>>> 
>>>>>>  2. I suppose JNFNewObjectArray could throw the OOM and we would get a parfait warning, could you please add CHECK_NULL_RETURN after it.
>>>>>    CHECK_NULL_RETURN is added.
>>>>>> 3. In CImage.java you are setting the currentImageIndex to the biggest image representation smaller that the one requested and this representation
>>>>>> would be used as a base one in the MultiResolutionBufferedImage. However in MultiResolutionBufferedImage getResolutionVariant you are returning
>>>>>> the smallest variant bigger than the requested one. Is this correct?
>>>>>    I think that it is correct. Assume that an image with size 300x300 is requested but there are only resolution variants with sizes [250x250] and [350x350].
>>>>>    The resolution variant with  [350x350] size is used as the base image.  Now we need to draw the image to region [300x300]. The resolution variant
>>>>>    with size [350x350] will be used from the MultiResolution image.
>>>>> 
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>> 
>>>>> 
>>>>>> Thank you.
>>>>>> With best regards. Petr.
>>>>>> 
>>>>>> On 26.02.2014, at 16:08, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>>>> 
>>>>>>>  Hello,
>>>>>>> 
>>>>>>>  Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>>>> 
>>>>>>>  This is the same fix. The only difference is that the MultiResolutionBufferedImage class is used from the fix JDK-8035069.
>>>>>>> 
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>>>>> Just to be clear, "the image representations are chosen to be closest to the requested size" is not accurate.
>>>>>>>> This change returns the smallest image representation that is greater than or equal to the requested size.  (Which I believe is the correct thing to do.)
>>>>>>>> A smaller image representation may be closer to the requested size, but it makes more sense to return a larger image since scaling down to size should produce better results than scaling up.
>>>>>>>> 
>>>>>>>> Scott
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>    Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>>>> 
>>>>>>>>     - The image representations are chosen to be closest to the
>>>>>>>>    requested size.
>>>>>>>> 
>>>>>>>>      Thanks,
>>>>>>>>      Alexandr.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>    On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>>>> 
>>>>>>>>        Hi, Alexander.
>>>>>>>>        I think that getResolutionVariant should return an image which
>>>>>>>>        is close as much as possible to the requested size.
>>>>>>>> 
>>>>>>>>        On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>            Hello,
>>>>>>>> 
>>>>>>>>            Could you review the fix:
>>>>>>>>              bug: https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>>>>              webrev:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>>>> 
>>>>>>>>            - The method that gets a sorted array of NSImage
>>>>>>>>            representaion pixel sizes for the given image size is added
>>>>>>>>            - A MultiResolution image is created if an NSImage has
>>>>>>>>            several representations for the given image size
>>>>>>>> 
>>>>>>>>            Thanks,
>>>>>>>>            Alexandr.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Tue Mar  4 04:12:57 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 04 Mar 2014 16:12:57 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <0C035A2D-21C9-4DA0-8054-7156A42E7F3C@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
	<5315B357.5030901@oracle.com>
	<A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>
	<5315BB8E.1030400@oracle.com>
	<0C035A2D-21C9-4DA0-8054-7156A42E7F3C@oracle.com>
Message-ID: <5315C349.5000801@oracle.com>

On 3/4/14 3:53 PM, Petr Pchelko wrote:
> I'm fine with the fix.
>
>>> Hello, Alexander.
>>>
>>> In CImage.m:430 - Do we really want to describe and clear the exception?
>>> May be it's better to simply return NULL and let Java handle the exception?
>>> This made sense when you were continuing the loop, but now doesn't.
>>    The exception is cleared because it should not be thrown on the Java side.
>>    For example the Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") call
>>    should not throw an exception in case if nativeGetNSImageRepresentationSizes() call fails.
>>    It should just return an Image without resolution variants.
>>    The ExceptionDescribe is left just for debugging purposes.
> In real life this will never happen, so I'm fine with any decision)
> Just CHECK_EXCEPTION_RETUEN looks nicer than these 3 lines.
I agree. If call to nativeGetNSImageRepresentationSizes will fail, will 
mean that some error exists in our code and it will be better to fail 
fast in this case, just return and throw and exception on java side.
>
> With best regards. Petr.
>
> On 04.03.2014, at 15:39, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>> On 3/4/2014 3:30 PM, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> In CImage.m:430 - Do we really want to describe and clear the exception?
>>> May be it's better to simply return NULL and let Java handle the exception?
>>> This made sense when you were continuing the loop, but now doesn't.
>>    The exception is cleared because it should not be thrown on the Java side.
>>    For example the Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") call
>>    should not throw an exception in case if nativeGetNSImageRepresentationSizes() call fails.
>>    It should just return an Image without resolution variants.
>>    The ExceptionDescribe is left just for debugging purposes.
>>
>>   Thanks,
>>   Alexandr.
>>
>>> With best regards. Petr.
>>>
>>> On 04.03.2014, at 15:04, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>>   Hello,
>>>>
>>>> Could you review the updated fix:
>>>>    http://cr.openjdk.java.net/~alexsch/8033534/webrev.04
>>>>
>>>>   - NULL is returned for all cases from the nativeGetNSImageRepresentationsCount method
>>>>   - long lines are split
>>>>   - SetObjectArrayElement can throw ArrayIndexOutOfBoundsException and ArrayStoreException exceptions.
>>>>     We do not expect neither of them because the same length and type is used for the array creation and element settings.
>>>>     I updated the exception handling to return NULL if an exception occurs.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>
>>>> On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
>>>>> Hi, Alexander.
>>>>> nativeGetNSImageRepresentationsCount three times return different values in case of error (0, NULL, nil).
>>>>> What exception we expect from the SetObjectArrayElement and why we continue in this case?
>>>>> Also please split soooooooooooooo long lines in these files.
>>>>>
>>>>> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>>>>> Hello,
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>>>>>
>>>>>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>>>>>> Hello, Alexander.
>>>>>>>
>>>>>>> I have a couple of comments:
>>>>>>>
>>>>>>> 1. You could replace the first loop with indexOfObjectPassingTest method.. Not sure if this would look cleaner, up to you.
>>>>>>     Updated. There is one more way to use one loop instead of two. All of them does not look simple.
>>>>>>
>>>>>>>   2. I suppose JNFNewObjectArray could throw the OOM and we would get a parfait warning, could you please add CHECK_NULL_RETURN after it.
>>>>>>     CHECK_NULL_RETURN is added.
>>>>>>> 3. In CImage.java you are setting the currentImageIndex to the biggest image representation smaller that the one requested and this representation
>>>>>>> would be used as a base one in the MultiResolutionBufferedImage. However in MultiResolutionBufferedImage getResolutionVariant you are returning
>>>>>>> the smallest variant bigger than the requested one. Is this correct?
>>>>>>     I think that it is correct. Assume that an image with size 300x300 is requested but there are only resolution variants with sizes [250x250] and [350x350].
>>>>>>     The resolution variant with  [350x350] size is used as the base image.  Now we need to draw the image to region [300x300]. The resolution variant
>>>>>>     with size [350x350] will be used from the MultiResolution image.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>
>>>>>>> Thank you.
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 26.02.2014, at 16:08, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>
>>>>>>>>   Hello,
>>>>>>>>
>>>>>>>>   Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>>>>>
>>>>>>>>   This is the same fix. The only difference is that the MultiResolutionBufferedImage class is used from the fix JDK-8035069.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>>>>>> Just to be clear, "the image representations are chosen to be closest to the requested size" is not accurate.
>>>>>>>>> This change returns the smallest image representation that is greater than or equal to the requested size.  (Which I believe is the correct thing to do.)
>>>>>>>>> A smaller image representation may be closer to the requested size, but it makes more sense to return a larger image since scaling down to size should produce better results than scaling up.
>>>>>>>>>
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>>>>>
>>>>>>>>>      - The image representations are chosen to be closest to the
>>>>>>>>>     requested size.
>>>>>>>>>
>>>>>>>>>       Thanks,
>>>>>>>>>       Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>>>>>
>>>>>>>>>         Hi, Alexander.
>>>>>>>>>         I think that getResolutionVariant should return an image which
>>>>>>>>>         is close as much as possible to the requested size.
>>>>>>>>>
>>>>>>>>>         On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             Hello,
>>>>>>>>>
>>>>>>>>>             Could you review the fix:
>>>>>>>>>               bug: https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>>>>>               webrev:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>>>>>
>>>>>>>>>             - The method that gets a sorted array of NSImage
>>>>>>>>>             representaion pixel sizes for the given image size is added
>>>>>>>>>             - A MultiResolution image is created if an NSImage has
>>>>>>>>>             several representations for the given image size
>>>>>>>>>
>>>>>>>>>             Thanks,
>>>>>>>>>             Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Mar  4 04:35:58 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 04 Mar 2014 16:35:58 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <5315C349.5000801@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
	<5315B357.5030901@oracle.com>
	<A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>
	<5315BB8E.1030400@oracle.com>
	<0C035A2D-21C9-4DA0-8054-7156A42E7F3C@oracle.com>
	<5315C349.5000801@oracle.com>
Message-ID: <5315C8AE.4030005@oracle.com>


  Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8033534/webrev.05/

   - JNU_CHECK_EXCEPTION_RETURN(env, NULL) after the 
SetObjectArrayElement call.
     Hope that the exception will never be thrown in the production code.

   Thanks,
   Alexandr.

On 3/4/2014 4:12 PM, Sergey Bylokhov wrote:
> On 3/4/14 3:53 PM, Petr Pchelko wrote:
>> I'm fine with the fix.
>>
>>>> Hello, Alexander.
>>>>
>>>> In CImage.m:430 - Do we really want to describe and clear the 
>>>> exception?
>>>> May be it's better to simply return NULL and let Java handle the 
>>>> exception?
>>>> This made sense when you were continuing the loop, but now doesn't.
>>>    The exception is cleared because it should not be thrown on the 
>>> Java side.
>>>    For example the 
>>> Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") 
>>> call
>>>    should not throw an exception in case if 
>>> nativeGetNSImageRepresentationSizes() call fails.
>>>    It should just return an Image without resolution variants.
>>>    The ExceptionDescribe is left just for debugging purposes.
>> In real life this will never happen, so I'm fine with any decision)
>> Just CHECK_EXCEPTION_RETUEN looks nicer than these 3 lines.
> I agree. If call to nativeGetNSImageRepresentationSizes will fail, 
> will mean that some error exists in our code and it will be better to 
> fail fast in this case, just return and throw and exception on java side.
>>
>> With best regards. Petr.
>>
>> On 04.03.2014, at 15:39, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com> wrote:
>>
>>> On 3/4/2014 3:30 PM, Petr Pchelko wrote:
>>>> Hello, Alexander.
>>>>
>>>> In CImage.m:430 - Do we really want to describe and clear the 
>>>> exception?
>>>> May be it's better to simply return NULL and let Java handle the 
>>>> exception?
>>>> This made sense when you were continuing the loop, but now doesn't.
>>>    The exception is cleared because it should not be thrown on the 
>>> Java side.
>>>    For example the 
>>> Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") 
>>> call
>>>    should not throw an exception in case if 
>>> nativeGetNSImageRepresentationSizes() call fails.
>>>    It should just return an Image without resolution variants.
>>>    The ExceptionDescribe is left just for debugging purposes.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>> With best regards. Petr.
>>>>
>>>> On 04.03.2014, at 15:04, Alexander Scherbatiy 
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>
>>>>>   Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>>    http://cr.openjdk.java.net/~alexsch/8033534/webrev.04
>>>>>
>>>>>   - NULL is returned for all cases from the 
>>>>> nativeGetNSImageRepresentationsCount method
>>>>>   - long lines are split
>>>>>   - SetObjectArrayElement can throw ArrayIndexOutOfBoundsException 
>>>>> and ArrayStoreException exceptions.
>>>>>     We do not expect neither of them because the same length and 
>>>>> type is used for the array creation and element settings.
>>>>>     I updated the exception handling to return NULL if an 
>>>>> exception occurs.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>> On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Alexander.
>>>>>> nativeGetNSImageRepresentationsCount three times return different 
>>>>>> values in case of error (0, NULL, nil).
>>>>>> What exception we expect from the SetObjectArrayElement and why 
>>>>>> we continue in this case?
>>>>>> Also please split soooooooooooooo long lines in these files.
>>>>>>
>>>>>> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>>   Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>>>>>>
>>>>>>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>>>>>>> Hello, Alexander.
>>>>>>>>
>>>>>>>> I have a couple of comments:
>>>>>>>>
>>>>>>>> 1. You could replace the first loop with 
>>>>>>>> indexOfObjectPassingTest method.. Not sure if this would look 
>>>>>>>> cleaner, up to you.
>>>>>>>     Updated. There is one more way to use one loop instead of 
>>>>>>> two. All of them does not look simple.
>>>>>>>
>>>>>>>>   2. I suppose JNFNewObjectArray could throw the OOM and we 
>>>>>>>> would get a parfait warning, could you please add 
>>>>>>>> CHECK_NULL_RETURN after it.
>>>>>>>     CHECK_NULL_RETURN is added.
>>>>>>>> 3. In CImage.java you are setting the currentImageIndex to the 
>>>>>>>> biggest image representation smaller that the one requested and 
>>>>>>>> this representation
>>>>>>>> would be used as a base one in the 
>>>>>>>> MultiResolutionBufferedImage. However in 
>>>>>>>> MultiResolutionBufferedImage getResolutionVariant you are 
>>>>>>>> returning
>>>>>>>> the smallest variant bigger than the requested one. Is this 
>>>>>>>> correct?
>>>>>>>     I think that it is correct. Assume that an image with size 
>>>>>>> 300x300 is requested but there are only resolution variants with 
>>>>>>> sizes [250x250] and [350x350].
>>>>>>>     The resolution variant with  [350x350] size is used as the 
>>>>>>> base image.  Now we need to draw the image to region [300x300]. 
>>>>>>> The resolution variant
>>>>>>>     with size [350x350] will be used from the MultiResolution 
>>>>>>> image.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>> Thank you.
>>>>>>>> With best regards. Petr.
>>>>>>>>
>>>>>>>> On 26.02.2014, at 16:08, Alexander Scherbatiy 
>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>>
>>>>>>>>>   Hello,
>>>>>>>>>
>>>>>>>>>   Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>>>>>>
>>>>>>>>>   This is the same fix. The only difference is that the 
>>>>>>>>> MultiResolutionBufferedImage class is used from the fix 
>>>>>>>>> JDK-8035069.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>>>>>>> Just to be clear, "the image representations are chosen to be 
>>>>>>>>>> closest to the requested size" is not accurate.
>>>>>>>>>> This change returns the smallest image representation that is 
>>>>>>>>>> greater than or equal to the requested size.  (Which I 
>>>>>>>>>> believe is the correct thing to do.)
>>>>>>>>>> A smaller image representation may be closer to the requested 
>>>>>>>>>> size, but it makes more sense to return a larger image since 
>>>>>>>>>> scaling down to size should produce better results than 
>>>>>>>>>> scaling up.
>>>>>>>>>>
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy 
>>>>>>>>>> <alexandr.scherbatiy at oracle.com 
>>>>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>>>>>>
>>>>>>>>>>      - The image representations are chosen to be closest to the
>>>>>>>>>>     requested size.
>>>>>>>>>>
>>>>>>>>>>       Thanks,
>>>>>>>>>>       Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>>>>>>
>>>>>>>>>>         Hi, Alexander.
>>>>>>>>>>         I think that getResolutionVariant should return an 
>>>>>>>>>> image which
>>>>>>>>>>         is close as much as possible to the requested size.
>>>>>>>>>>
>>>>>>>>>>         On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>             Hello,
>>>>>>>>>>
>>>>>>>>>>             Could you review the fix:
>>>>>>>>>>               bug: 
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>>>>>>               webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>>>>>>
>>>>>>>>>>             - The method that gets a sorted array of NSImage
>>>>>>>>>>             representaion pixel sizes for the given image 
>>>>>>>>>> size is added
>>>>>>>>>>             - A MultiResolution image is created if an 
>>>>>>>>>> NSImage has
>>>>>>>>>>             several representations for the given image size
>>>>>>>>>>
>>>>>>>>>>             Thanks,
>>>>>>>>>>             Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>
>


From Sergey.Bylokhov at oracle.com  Tue Mar  4 04:41:45 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 04 Mar 2014 16:41:45 +0400
Subject: <AWT Dev> [9] Review request for 8033534 Get MultiResolution
	image from native system
In-Reply-To: <5315C8AE.4030005@oracle.com>
References: <52F0E01B.3050004@oracle.com> <52F0E466.6040002@oracle.com>
	<52F8D9C2.70600@oracle.com>
	<CAL3e5iGCsiwqgm9YZF9JPj2ani0urO-WqCXa4r0w=T=L+2Wptg@mail.gmail.com>
	<530DD955.5010702@oracle.com>
	<BFC2B120-C29E-40EB-A157-9E298A375D6D@oracle.com>
	<530DFCE6.2020508@oracle.com> <5314DC90.4030509@oracle.com>
	<5315B357.5030901@oracle.com>
	<A690D8DB-EFE8-47B8-A94D-A7C1E5E1E405@oracle.com>
	<5315BB8E.1030400@oracle.com>
	<0C035A2D-21C9-4DA0-8054-7156A42E7F3C@oracle.com>
	<5315C349.5000801@oracle.com> <5315C8AE.4030005@oracle.com>
Message-ID: <5315CA09.9010204@oracle.com>

On 3/4/14 4:35 PM, Alexander Scherbatiy wrote:
>
>  Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8033534/webrev.05/
>
>   - JNU_CHECK_EXCEPTION_RETURN(env, NULL) after the 
> SetObjectArrayElement call.
>     Hope that the exception will never be thrown in the production code.
Thanks. The fix looks good.

>
>   Thanks,
>   Alexandr.
>
> On 3/4/2014 4:12 PM, Sergey Bylokhov wrote:
>> On 3/4/14 3:53 PM, Petr Pchelko wrote:
>>> I'm fine with the fix.
>>>
>>>>> Hello, Alexander.
>>>>>
>>>>> In CImage.m:430 - Do we really want to describe and clear the 
>>>>> exception?
>>>>> May be it's better to simply return NULL and let Java handle the 
>>>>> exception?
>>>>> This made sense when you were continuing the loop, but now doesn't.
>>>>    The exception is cleared because it should not be thrown on the 
>>>> Java side.
>>>>    For example the 
>>>> Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") 
>>>> call
>>>>    should not throw an exception in case if 
>>>> nativeGetNSImageRepresentationSizes() call fails.
>>>>    It should just return an Image without resolution variants.
>>>>    The ExceptionDescribe is left just for debugging purposes.
>>> In real life this will never happen, so I'm fine with any decision)
>>> Just CHECK_EXCEPTION_RETUEN looks nicer than these 3 lines.
>> I agree. If call to nativeGetNSImageRepresentationSizes will fail, 
>> will mean that some error exists in our code and it will be better to 
>> fail fast in this case, just return and throw and exception on java 
>> side.
>>>
>>> With best regards. Petr.
>>>
>>> On 04.03.2014, at 15:39, Alexander Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>> On 3/4/2014 3:30 PM, Petr Pchelko wrote:
>>>>> Hello, Alexander.
>>>>>
>>>>> In CImage.m:430 - Do we really want to describe and clear the 
>>>>> exception?
>>>>> May be it's better to simply return NULL and let Java handle the 
>>>>> exception?
>>>>> This made sense when you were continuing the loop, but now doesn't.
>>>>    The exception is cleared because it should not be thrown on the 
>>>> Java side.
>>>>    For example the 
>>>> Toolkit.getDefaultToolkit().getImage("NSImage://NSApplicationIcon") 
>>>> call
>>>>    should not throw an exception in case if 
>>>> nativeGetNSImageRepresentationSizes() call fails.
>>>>    It should just return an Image without resolution variants.
>>>>    The ExceptionDescribe is left just for debugging purposes.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>> On 04.03.2014, at 15:04, Alexander Scherbatiy 
>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>
>>>>>>   Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>>    http://cr.openjdk.java.net/~alexsch/8033534/webrev.04
>>>>>>
>>>>>>   - NULL is returned for all cases from the 
>>>>>> nativeGetNSImageRepresentationsCount method
>>>>>>   - long lines are split
>>>>>>   - SetObjectArrayElement can throw 
>>>>>> ArrayIndexOutOfBoundsException and ArrayStoreException exceptions.
>>>>>>     We do not expect neither of them because the same length and 
>>>>>> type is used for the array creation and element settings.
>>>>>>     I updated the exception handling to return NULL if an 
>>>>>> exception occurs.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>
>>>>>> On 3/3/2014 11:48 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Alexander.
>>>>>>> nativeGetNSImageRepresentationsCount three times return 
>>>>>>> different values in case of error (0, NULL, nil).
>>>>>>> What exception we expect from the SetObjectArrayElement and why 
>>>>>>> we continue in this case?
>>>>>>> Also please split soooooooooooooo long lines in these files.
>>>>>>>
>>>>>>> On 2/26/14 6:40 PM, Alexander Scherbatiy wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>   Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.03/
>>>>>>>>
>>>>>>>> On 2/26/2014 4:54 PM, Petr Pchelko wrote:
>>>>>>>>> Hello, Alexander.
>>>>>>>>>
>>>>>>>>> I have a couple of comments:
>>>>>>>>>
>>>>>>>>> 1. You could replace the first loop with 
>>>>>>>>> indexOfObjectPassingTest method.. Not sure if this would look 
>>>>>>>>> cleaner, up to you.
>>>>>>>>     Updated. There is one more way to use one loop instead of 
>>>>>>>> two. All of them does not look simple.
>>>>>>>>
>>>>>>>>>   2. I suppose JNFNewObjectArray could throw the OOM and we 
>>>>>>>>> would get a parfait warning, could you please add 
>>>>>>>>> CHECK_NULL_RETURN after it.
>>>>>>>>     CHECK_NULL_RETURN is added.
>>>>>>>>> 3. In CImage.java you are setting the currentImageIndex to the 
>>>>>>>>> biggest image representation smaller that the one requested 
>>>>>>>>> and this representation
>>>>>>>>> would be used as a base one in the 
>>>>>>>>> MultiResolutionBufferedImage. However in 
>>>>>>>>> MultiResolutionBufferedImage getResolutionVariant you are 
>>>>>>>>> returning
>>>>>>>>> the smallest variant bigger than the requested one. Is this 
>>>>>>>>> correct?
>>>>>>>>     I think that it is correct. Assume that an image with size 
>>>>>>>> 300x300 is requested but there are only resolution variants 
>>>>>>>> with sizes [250x250] and [350x350].
>>>>>>>>     The resolution variant with  [350x350] size is used as the 
>>>>>>>> base image.  Now we need to draw the image to region [300x300]. 
>>>>>>>> The resolution variant
>>>>>>>>     with size [350x350] will be used from the MultiResolution 
>>>>>>>> image.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>> With best regards. Petr.
>>>>>>>>>
>>>>>>>>> On 26.02.2014, at 16:08, Alexander Scherbatiy 
>>>>>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>>   Hello,
>>>>>>>>>>
>>>>>>>>>>   Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.02/
>>>>>>>>>>
>>>>>>>>>>   This is the same fix. The only difference is that the 
>>>>>>>>>> MultiResolutionBufferedImage class is used from the fix 
>>>>>>>>>> JDK-8035069.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2/10/2014 7:05 PM, Scott Palmer wrote:
>>>>>>>>>>> Just to be clear, "the image representations are chosen to 
>>>>>>>>>>> be closest to the requested size" is not accurate.
>>>>>>>>>>> This change returns the smallest image representation that 
>>>>>>>>>>> is greater than or equal to the requested size.  (Which I 
>>>>>>>>>>> believe is the correct thing to do.)
>>>>>>>>>>> A smaller image representation may be closer to the 
>>>>>>>>>>> requested size, but it makes more sense to return a larger 
>>>>>>>>>>> image since scaling down to size should produce better 
>>>>>>>>>>> results than scaling up.
>>>>>>>>>>>
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Feb 10, 2014 at 8:53 AM, Alexander Scherbatiy 
>>>>>>>>>>> <alexandr.scherbatiy at oracle.com 
>>>>>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.01
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.01>
>>>>>>>>>>>
>>>>>>>>>>>      - The image representations are chosen to be closest to 
>>>>>>>>>>> the
>>>>>>>>>>>     requested size.
>>>>>>>>>>>
>>>>>>>>>>>       Thanks,
>>>>>>>>>>>       Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     On 2/4/2014 5:00 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>
>>>>>>>>>>>         Hi, Alexander.
>>>>>>>>>>>         I think that getResolutionVariant should return an 
>>>>>>>>>>> image which
>>>>>>>>>>>         is close as much as possible to the requested size.
>>>>>>>>>>>
>>>>>>>>>>>         On 04.02.2014 16:42, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>             Hello,
>>>>>>>>>>>
>>>>>>>>>>>             Could you review the fix:
>>>>>>>>>>>               bug: 
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033534
>>>>>>>>>>>               webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8033534/webrev.00
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8033534/webrev.00>
>>>>>>>>>>>
>>>>>>>>>>>             - The method that gets a sorted array of NSImage
>>>>>>>>>>>             representaion pixel sizes for the given image 
>>>>>>>>>>> size is added
>>>>>>>>>>>             - A MultiResolution image is created if an 
>>>>>>>>>>> NSImage has
>>>>>>>>>>>             several representations for the given image size
>>>>>>>>>>>
>>>>>>>>>>>             Thanks,
>>>>>>>>>>>             Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> -- 
>>>>>>> Best regards, Sergey.
>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Mar  4 05:32:03 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 04 Mar 2014 17:32:03 +0400
Subject: [9] Review request for 8036598 [macosx] Create AquaIcons from image
	representations
Message-ID: <5315D5D3.9040403@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8036598
   webrev: http://cr.openjdk.java.net/~alexsch/8036598/webrev.00

   The fix creates an AquaIcon based on resolution variants.
   It becomes possible after the fix 8033534 where CImage returns
   a MultiResolution image based on NSImage representations.


Thanks,
Alexandr.


From petr.pchelko at oracle.com  Tue Mar  4 05:55:47 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 4 Mar 2014 17:55:47 +0400
Subject: [9] Review request for 8036598 [macosx] Create AquaIcons from
	image representations
In-Reply-To: <5315D5D3.9040403@oracle.com>
References: <5315D5D3.9040403@oracle.com>
Message-ID: <A5A4D2CE-9D35-4A9D-8E82-541CC3AFEB51@oracle.com>

Hello, Alexander.

I've been also looking around this code and I have a related question: 
when we call getThisApplicationsIcon we are drawing the Dock icon on top of a multi-resolution background image. 
However as I see, the dock icon image created with getThisApplicationsIcon and getGenericJavaIcon is not a 
multi-resolution image and the requested size we pass in is ignored. Does it worth updating too, so that we could receive 
the dock icon as a multi-resolution image also and then choose the representation which fits kAlertSubIconSize best to avoid 
too big downscaling?

Thank you.
With best regards. Petr.

On 04.03.2014, at 17:32, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
> Hello,
> 
> Could you review the fix:
>  bug: https://bugs.openjdk.java.net/browse/JDK-8036598
>  webrev: http://cr.openjdk.java.net/~alexsch/8036598/webrev.00
> 
>  The fix creates an AquaIcon based on resolution variants.
>  It becomes possible after the fix 8033534 where CImage returns
>  a MultiResolution image based on NSImage representations.
> 
> 
> Thanks,
> Alexandr.
> 


From Sergey.Bylokhov at oracle.com  Tue Mar  4 06:11:39 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 04 Mar 2014 18:11:39 +0400
Subject: [9] Review request for 8036598 [macosx] Create AquaIcons from
	image representations
In-Reply-To: <5315D5D3.9040403@oracle.com>
References: <5315D5D3.9040403@oracle.com>
Message-ID: <5315DF1B.4070700@oracle.com>

Hi, Alexander.
I have only two suggestions about MultiResolutionBufferedImage
  - It could be final and its fields can be private final.
  - .toArray(length -> new Image[length])); can be replaced 
.toArray(Image[]::new));

On 3/4/14 5:32 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8036598
>   webrev: http://cr.openjdk.java.net/~alexsch/8036598/webrev.00
>
>   The fix creates an AquaIcon based on resolution variants.
>   It becomes possible after the fix 8033534 where CImage returns
>   a MultiResolution image based on NSImage representations.
>
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.


From hs at tagtraum.com  Thu Mar  6 00:01:23 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 6 Mar 2014 09:01:23 +0100
Subject: Space character as accelerator in JMenuItem not rendered (correctly)
Message-ID: <56132FC8-F89B-486B-8B91-151A863F6808@tagtraum.com>

Hi,

when using the space character as accelerator for a JMenuItem, it is not rendered correctly (I guess a ' ' is rendered, but that's kind of hard to see ;-).
OS X applications like iTunes (in the controls menu) do render the word "Space", localized to the current locale.

This is how it fails:

action.putValue(Action.ACCELERATOR_KEY, KeyStroke.getKeyStroke(KeyEvent.VK_SPACE, 0));
new JMenuItem(action);

Is this a known issue? I wasn't able to find it on https://bugs.openjdk.java.net

Thanks,

-hendrik


From private at claudio.ch  Thu Mar  6 12:23:59 2014
From: private at claudio.ch (Claudio Nieder)
Date: Thu, 6 Mar 2014 21:23:59 +0100
Subject: JDK-8033808 Cannot enable Java in Browser
Message-ID: <6FF9CF65-A600-44B2-B418-54B7FF179990@claudio.ch>

Hi,

I wonder a few things about this bug, as it was selected to defer the fix to 8u20:

An OSX user has Java 1.7 currently. When Java 1.8 becomes available will it show in the preference panel, that a new version is available and suggest an upgrade from 1.7.0_51 to 1.8.0 or will the Java Preference pane only suggest upgrades to newer 1.7.0 versions?

If Java content in browser is disabled and the user does an update to 1.8, either because suggested by the update panel or because he just heard there is a new and improved Java version, and the user wants afterwards to enable Java in Broswer is there a way for the user to go back to 1.7? I ask this, because I have just done

$ sudo rm -r /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk
$ java_home -V
Matching Java Virtual Machines (3):
    1.7.0_51, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
    1.6.0_65-b14-462, x86_64:	"Java SE 6"	/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
    1.6.0_65-b14-462, i386:	"Java SE 6"	/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home

yet when I open System Preferences and from there the Java Control Panel the About... still tells me 1.8.0-b129 and I still cannot enable Java in the Browser.

Also how likely is above scenario? I wonder as I seem to have heard that some 1.7 updates did disable Java in Browser as a security measure and the user would have to switch it on again if needed. So could it therefore be a very likely scenario, that a user upgrades to 1.8 and is then stuck with Java permanently disabled in the browser (at least until 8u20 fixes the issue)?

claudio
-- 
Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch





From david.dehaven at oracle.com  Thu Mar  6 15:27:54 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 6 Mar 2014 15:27:54 -0800
Subject: JDK-8033808 Cannot enable Java in Browser
In-Reply-To: <6FF9CF65-A600-44B2-B418-54B7FF179990@claudio.ch>
References: <6FF9CF65-A600-44B2-B418-54B7FF179990@claudio.ch>
Message-ID: <0EC64D08-016D-4995-9792-85B1BA5BF527@oracle.com>


> $ sudo rm -r /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk
> $ java_home -V
> Matching Java Virtual Machines (3):
>    1.7.0_51, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
>    1.6.0_65-b14-462, x86_64:	"Java SE 6"	/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>    1.6.0_65-b14-462, i386:	"Java SE 6"	/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

You're confusing JDK with the JRE. The Java Control Panel has nothing to do with any of the JDKs installed on the system and they will never be used by the plugin or javaws (including double-clicking on a jar in Finder) nor will they be listed as available JREs in the Java Control Panel (because they're not valid JREs... they lack deployment components). Likewise, java_home does not track the JRE since it's intended to be used with JDK bundles.

The JRE is always installed to:
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin

When it's updated, it's done in-situ, replacing the old version. We do not track any other installation locations. You can downgrade to 7 by deleting JavaAppletPlugin.plugin and running the Java 7 JRE installer.

-DrD-


From hs at tagtraum.com  Wed Mar 12 09:35:50 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Wed, 12 Mar 2014 10:35:50 +0100
Subject: RFE: SecretKeyEntry support for Apple KeychainStore
Message-ID: <1A2D3048-4396-4E60-86ED-3D0A6481CECF@tagtraum.com>

Hey...

I was pleasantly surprised to learn that Apple and subsequently OpenJDK provides support for using the Apple KeyChain as a keystore.
As I common use case, I tried to use it to store passwords for third party services (Twitter, git, whatever), but couldn't get it to work.

Apparently the implementation lacks support for SecretKeyEntry, as pointed out in http://stackoverflow.com/questions/727812/storing-username-password-on-mac-using-java#727840

Would it be possible to implement this?

Thanks,

-hendrik

PS: As illustration, I would expect the following code to work (it works with JCEKS as KeyStore and appropriate input/output streams in load/store calls):

final char[] keyStorePassword = "KeyStorePassword".toCharArray();
final char[] servicePassword = "ServicePassword".toCharArray();
final String alias = "MyService";

// store password for some service
final KeyStore keystore = KeyStore.getInstance("KeychainStore", "Apple");
keystore.load(null, keyStorePassword);

final KeyStore.PasswordProtection keyStorePP = new KeyStore.PasswordProtection(keyStorePassword);

final SecretKeyFactory factory = SecretKeyFactory.getInstance("PBE");
final SecretKey generatedSecret = factory.generateSecret(new PBEKeySpec(servicePassword));
keystore.setEntry(alias, new KeyStore.SecretKeyEntry(generatedSecret), keyStorePP);

keystore.store(null, keyStorePassword);

// retrieve password for some service
final KeyStore keystore2 = KeyStore.getInstance("KeychainStore", "Apple");
keystore2.load(null, keyStorePassword);

final KeyStore.SecretKeyEntry secretKeyEntry = (KeyStore.SecretKeyEntry)keystore2.getEntry(alias, keyStorePP);
final PBEKeySpec keySpec = (PBEKeySpec)factory.getKeySpec(secretKeyEntry.getSecretKey(), PBEKeySpec.class);

char[] password = keySpec.getPassword();
System.out.println(new String(password));


From mik3hall at gmail.com  Wed Mar 12 10:59:13 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 12 Mar 2014 05:59:13 -0500
Subject: RFE: SecretKeyEntry support for Apple KeychainStore
In-Reply-To: <1A2D3048-4396-4E60-86ED-3D0A6481CECF@tagtraum.com>
References: <1A2D3048-4396-4E60-86ED-3D0A6481CECF@tagtraum.com>
Message-ID: <F00FF48F-8339-4176-9D7C-43CE1A86A37B@gmail.com>

On Mar 12, 2014, at 4:35 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:


> Hey...
> 
> I was pleasantly surprised to learn that Apple and subsequently OpenJDK provides support for using the Apple KeyChain as a keystore.
> As I common use case, I tried to use it to store passwords for third party services (Twitter, git, whatever), but couldn't get it to work.
> 
> Apparently the implementation lacks support for SecretKeyEntry, as pointed out in http://stackoverflow.com/questions/727812/storing-username-password-on-mac-using-java#727840


The stackoverflow entry seems correct that password entries don't show alias's.

java -cp . KeyStoreTester | grep github
KeychainStore Ignored Exception: java.security.cert.CertificateException: Signature algorithm mismatch
KeychainStore Ignored Exception: java.security.cert.CertificateParsingException: java.io.IOException: Duplicate extensions not allowed

Shows nothing for a password, it does show keys & certs, but it also oddly gets a couple exceptions.

import java.security.*;
import java.util.Enumeration;

public class KeyStoreTester {

	public static void main(String[] args) {
		try {
			KeyStore ks = KeyStore.getInstance("KeychainStore","Apple");
			ks.load(null,"ANY".toCharArray());
			System.out.println(ks.getProvider());
			Enumeration<String> e = ks.aliases();
			while (e.hasMoreElements())
				System.out.println(e.nextElement());
		}
		catch (Exception ex) { ex.printStackTrace(); }	
	}
	
}

java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter




From alexandr.scherbatiy at oracle.com  Wed Mar 12 15:03:08 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 12 Mar 2014 19:03:08 +0400
Subject: [9] Review request for 8035069 [macosx] Loading resolution variants
	by demand
Message-ID: <5320772C.40909@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8035069
   webrev: http://cr.openjdk.java.net/~alexsch/8035069/webrev.00

   Image resolution variants are generated by request and cached in the 
ImageCache.

   - ImageCache is refactored to store different type of images and 
moved to sun.awt.image package.
   - An object is used as the cache key instead of hash code to prevent 
inetsection of hash codes for
     different type of images.
   - The base image for MultiResolutionBufferedImage is not cached and 
used for the hash code calculation
     in the getResolutionVariant method.

Thanks,
Alexandr.


From petr.pchelko at oracle.com  Thu Mar 13 08:21:25 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 13 Mar 2014 12:21:25 +0400
Subject: [9] Review request for 8035069 [macosx] Loading resolution
	variants by demand
In-Reply-To: <5320772C.40909@oracle.com>
References: <5320772C.40909@oracle.com>
Message-ID: <C695F79C-DB30-4E1C-B2C8-92774297E05F@oracle.com>

Hello, Alexander.

1. As Sergey always says, could you please split the long lines.
2. Instead of the MultiResolutionImageMapper you could use a BiFunction<Image, Integer, Integer>
3. About the ImageCache. As it's uses an AppContext, could you please mention in the JavaDoc that is must be used from the thread with an AppContext only?
4. I don't really like that you are duplicating the RecyclableSingleton class. May be it's better to make also move it out from com.apple.laf and reuse?
5. Looks like the old ImageCache contained the following lines:

 116 if (state.is(JRSUIConstants.Animating.YES)) {
 117     return false;
 118 } 
I agree that these are probably not needed, but could you please verify that? Also after these were removed the ImageCache.setImage never returns false, so it could be made void.

With best regards. Petr.

On 12.03.2014, at 19:03, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
> Hello,
> 
> Could you review the fix:
>  bug: https://bugs.openjdk.java.net/browse/JDK-8035069
>  webrev: http://cr.openjdk.java.net/~alexsch/8035069/webrev.00
> 
>  Image resolution variants are generated by request and cached in the ImageCache.
> 
>  - ImageCache is refactored to store different type of images and moved to sun.awt.image package.
>  - An object is used as the cache key instead of hash code to prevent inetsection of hash codes for
>    different type of images.
>  - The base image for MultiResolutionBufferedImage is not cached and used for the hash code calculation
>    in the getResolutionVariant method.
> 
> Thanks,
> Alexandr.
> 


From alexandr.scherbatiy at oracle.com  Fri Mar 14 15:53:29 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 14 Mar 2014 19:53:29 +0400
Subject: [9] Review request for 8035069 [macosx] Loading resolution
	variants by demand
In-Reply-To: <C695F79C-DB30-4E1C-B2C8-92774297E05F@oracle.com>
References: <5320772C.40909@oracle.com>
	<C695F79C-DB30-4E1C-B2C8-92774297E05F@oracle.com>
Message-ID: <532325F9.7090405@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8035069/webrev.01

On 3/13/2014 12:21 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> 1. As Sergey always says, could you please split the long lines.
> 2. Instead of the MultiResolutionImageMapper you could use a BiFunction<Image, Integer, Integer>
> 3. About the ImageCache. As it's uses an AppContext, could you please mention in the JavaDoc that is must be used from the thread with an AppContext only?
      1. 2. and 3 are updated.
> 4. I don't really like that you are duplicating the RecyclableSingleton class. May be it's better to make also move it out from com.apple.laf and reuse?
       I have added the getSoftReferenceValue(Object key, Supplier<T> 
supplier) method to the AppContext class. It should reduce the code 
duplication.
> 5. Looks like the old ImageCache contained the following lines:
>
>   116 if (state.is(JRSUIConstants.Animating.YES)) {
>   117     return false;
>   118 }
> I agree that these are probably not needed, but could you please verify that? Also after these were removed the ImageCache.setImage never returns false, so it could be made void.
      Thank you for pointing it out. This is the necessary check for the 
animated images in the Aqua L&F. I just forgot to move it to the 
AquaPainter.

      I have found one more issue that ImageIcon preloads images by 
calling image.getProperty("comment", imageObserver) where the imageObserver
      is usually null. The MultiResolutionBufferedImage created 
non-preloaded resolution variants and they were not shown because 
JMenuItem as an image observer
      returns false for the image loading. This is described in the 
issue 8037405 JMenuItem should check L&F icons in the image observer
         https://bugs.openjdk.java.net/browse/JDK-8037405

       It seems as a common problem so I added resolution variants 
preloading to the MultiResolutionBufferedImage.

    Thanks,
    Alexandr.
> With best regards. Petr.
>
> On 12.03.2014, at 19:03, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8035069
>>   webrev: http://cr.openjdk.java.net/~alexsch/8035069/webrev.00
>>
>>   Image resolution variants are generated by request and cached in the ImageCache.
>>
>>   - ImageCache is refactored to store different type of images and moved to sun.awt.image package.
>>   - An object is used as the cache key instead of hash code to prevent inetsection of hash codes for
>>     different type of images.
>>   - The base image for MultiResolutionBufferedImage is not cached and used for the hash code calculation
>>     in the getResolutionVariant method.
>>
>> Thanks,
>> Alexandr.
>>


From petr.pchelko at oracle.com  Fri Mar 14 18:38:13 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 14 Mar 2014 22:38:13 +0400
Subject: [9] Review request for 8035069 [macosx] Loading resolution
	variants by demand
In-Reply-To: <532325F9.7090405@oracle.com>
References: <5320772C.40909@oracle.com>
	<C695F79C-DB30-4E1C-B2C8-92774297E05F@oracle.com>
	<532325F9.7090405@oracle.com>
Message-ID: <76BC8568-0664-4043-BE2F-88836E97EFF9@oracle.com>

Hello, Alexander.

The updated version of the fix looks good to me.

With best regards. Petr.

14 ????? 2014 ?., ? 7:53 ????? ???????, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> ???????(?):

> 
> Hello,
> 
> Could you review the updated fix:
>  http://cr.openjdk.java.net/~alexsch/8035069/webrev.01
> 
> On 3/13/2014 12:21 PM, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> 1. As Sergey always says, could you please split the long lines.
>> 2. Instead of the MultiResolutionImageMapper you could use a BiFunction<Image, Integer, Integer>
>> 3. About the ImageCache. As it's uses an AppContext, could you please mention in the JavaDoc that is must be used from the thread with an AppContext only?
>     1. 2. and 3 are updated.
>> 4. I don't really like that you are duplicating the RecyclableSingleton class. May be it's better to make also move it out from com.apple.laf and reuse?
>      I have added the getSoftReferenceValue(Object key, Supplier<T> supplier) method to the AppContext class. It should reduce the code duplication.
>> 5. Looks like the old ImageCache contained the following lines:
>> 
>>  116 if (state.is(JRSUIConstants.Animating.YES)) {
>>  117     return false;
>>  118 }
>> I agree that these are probably not needed, but could you please verify that? Also after these were removed the ImageCache.setImage never returns false, so it could be made void.
>     Thank you for pointing it out. This is the necessary check for the animated images in the Aqua L&F. I just forgot to move it to the AquaPainter.
> 
>     I have found one more issue that ImageIcon preloads images by calling image.getProperty("comment", imageObserver) where the imageObserver
>     is usually null. The MultiResolutionBufferedImage created non-preloaded resolution variants and they were not shown because JMenuItem as an image observer
>     returns false for the image loading. This is described in the issue 8037405 JMenuItem should check L&F icons in the image observer
>        https://bugs.openjdk.java.net/browse/JDK-8037405
> 
>      It seems as a common problem so I added resolution variants preloading to the MultiResolutionBufferedImage.
> 
>   Thanks,
>   Alexandr.
>> With best regards. Petr.
>> 
>> On 12.03.2014, at 19:03, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could you review the fix:
>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8035069
>>>  webrev: http://cr.openjdk.java.net/~alexsch/8035069/webrev.00
>>> 
>>>  Image resolution variants are generated by request and cached in the ImageCache.
>>> 
>>>  - ImageCache is refactored to store different type of images and moved to sun.awt.image package.
>>>  - An object is used as the cache key instead of hash code to prevent inetsection of hash codes for
>>>    different type of images.
>>>  - The base image for MultiResolutionBufferedImage is not cached and used for the hash code calculation
>>>    in the getResolutionVariant method.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
> 


From Sergey.Bylokhov at oracle.com  Mon Mar 17 12:09:41 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Mar 2014 16:09:41 +0400
Subject: [9] Review request for 8035069 [macosx] Loading resolution
	variants by demand
In-Reply-To: <76BC8568-0664-4043-BE2F-88836E97EFF9@oracle.com>
References: <5320772C.40909@oracle.com>
	<C695F79C-DB30-4E1C-B2C8-92774297E05F@oracle.com>
	<532325F9.7090405@oracle.com>
	<76BC8568-0664-4043-BE2F-88836E97EFF9@oracle.com>
Message-ID: <5326E605.50606@oracle.com>

Hello, Alexander.
The fix looks good to me too. Thanks!

On 3/14/14 10:38 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> The updated version of the fix looks good to me.
>
> With best regards. Petr.
>
> 14 ????? 2014 ?., ? 7:53 ????? ???????, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> ???????(?):
>
>> Hello,
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8035069/webrev.01
>>
>> On 3/13/2014 12:21 PM, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> 1. As Sergey always says, could you please split the long lines.
>>> 2. Instead of the MultiResolutionImageMapper you could use a BiFunction<Image, Integer, Integer>
>>> 3. About the ImageCache. As it's uses an AppContext, could you please mention in the JavaDoc that is must be used from the thread with an AppContext only?
>>      1. 2. and 3 are updated.
>>> 4. I don't really like that you are duplicating the RecyclableSingleton class. May be it's better to make also move it out from com.apple.laf and reuse?
>>       I have added the getSoftReferenceValue(Object key, Supplier<T> supplier) method to the AppContext class. It should reduce the code duplication.
>>> 5. Looks like the old ImageCache contained the following lines:
>>>
>>>   116 if (state.is(JRSUIConstants.Animating.YES)) {
>>>   117     return false;
>>>   118 }
>>> I agree that these are probably not needed, but could you please verify that? Also after these were removed the ImageCache.setImage never returns false, so it could be made void.
>>      Thank you for pointing it out. This is the necessary check for the animated images in the Aqua L&F. I just forgot to move it to the AquaPainter.
>>
>>      I have found one more issue that ImageIcon preloads images by calling image.getProperty("comment", imageObserver) where the imageObserver
>>      is usually null. The MultiResolutionBufferedImage created non-preloaded resolution variants and they were not shown because JMenuItem as an image observer
>>      returns false for the image loading. This is described in the issue 8037405 JMenuItem should check L&F icons in the image observer
>>         https://bugs.openjdk.java.net/browse/JDK-8037405
>>
>>       It seems as a common problem so I added resolution variants preloading to the MultiResolutionBufferedImage.
>>
>>    Thanks,
>>    Alexandr.
>>> With best regards. Petr.
>>>
>>> On 12.03.2014, at 19:03, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8035069
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8035069/webrev.00
>>>>
>>>>   Image resolution variants are generated by request and cached in the ImageCache.
>>>>
>>>>   - ImageCache is refactored to store different type of images and moved to sun.awt.image package.
>>>>   - An object is used as the cache key instead of hash code to prevent inetsection of hash codes for
>>>>     different type of images.
>>>>   - The base image for MultiResolutionBufferedImage is not cached and used for the hash code calculation
>>>>     in the getResolutionVariant method.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar 19 15:27:22 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Mar 2014 19:27:22 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC on
	Mac with monitor sleeping
Message-ID: <5329B75A.7010204@oracle.com>

Hello.
Please review the fix for jdk 9.
After the fix we use screen in sleep state as normal screen, where we 
can create new windows, etc.
Disadvantage is that Robot still does not work on such devices.

Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
Webrev can be found at: http://cr.openjdk.java.net/~serb/7124417/webrev.01

-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Mar 19 17:20:55 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 19 Mar 2014 21:20:55 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329B75A.7010204@oracle.com>
References: <5329B75A.7010204@oracle.com>
Message-ID: <5329D1F7.5060902@oracle.com>

Hi Sergey,

Generally the fix looks good. I have only two concerns:

1. Previously we didn't exclude mirrored displays from the list. So the 
new code that you're adding at lines 84-92 might be better integrated as 
a separate fix.

2. Before the fix, the list of display devices returned from 
getDisplayIDs was in the same order as reported by the native system. 
After your fix the order is reversed. For instance, if previously the 
main display was always at index [0], not it's always at the tail of the 
array. This may or may not be a problem for Java applications (likely 
not a serious problem). However, keeping the same order between Java and 
native APIs might be a good thing for debugging purposes. Would it be 
possible to modify the loop at lines 103-106 to preserve the order?

--
best regards,
Anthony

On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> After the fix we use screen in sleep state as normal screen, where we
> can create new windows, etc.
> Disadvantage is that Robot still does not work on such devices.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124417/webrev.01
>

From Sergey.Bylokhov at oracle.com  Wed Mar 19 17:29:26 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Mar 2014 21:29:26 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329D1F7.5060902@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
Message-ID: <5329D3F6.5040004@oracle.com>

Hello, Anthony.
On 3/19/14 9:20 PM, Anthony Petrov wrote:
> Hi Sergey,
>
> Generally the fix looks good. I have only two concerns:
>
> 1. Previously we didn't exclude mirrored displays from the list. So 
> the new code that you're adding at lines 84-92 might be better 
> integrated as a separate fix.
Before the fix we use CGGetActiveDisplayList, which returns only active 
device w/o device in sleep or mirror state. The new function 
CGGetOnlineDisplayList return all of them and we should filter out 
mirror device.
>
> 2. Before the fix, the list of display devices returned from 
> getDisplayIDs was in the same order as reported by the native system. 
> After your fix the order is reversed. For instance, if previously the 
> main display was always at index [0], not it's always at the tail of 
> the array. This may or may not be a problem for Java applications 
> (likely not a serious problem). However, keeping the same order 
> between Java and native APIs might be a good thing for debugging 
> purposes. Would it be possible to modify the loop at lines 103-106 to 
> preserve the order?
It is not necessary, because we store them in the Map on java side anyway.
>
> -- 
> best regards,
> Anthony
>
> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 9.
>> After the fix we use screen in sleep state as normal screen, where we
>> can create new windows, etc.
>> Disadvantage is that Robot still does not work on such devices.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Mar 19 17:35:14 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 19 Mar 2014 21:35:14 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329D3F6.5040004@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com>
Message-ID: <5329D552.90400@oracle.com>

On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>> 1. Previously we didn't exclude mirrored displays from the list. So
>> the new code that you're adding at lines 84-92 might be better
>> integrated as a separate fix.
> Before the fix we use CGGetActiveDisplayList, which returns only active
> device w/o device in sleep or mirror state. The new function
> CGGetOnlineDisplayList return all of them and we should filter out
> mirror device.

The specification of CGGetActiveDisplayList suggests that in the case of 
software mirroring the returned list includes all mirror devices. 
Therefore I still think that this is a separate bug.


>> 2. Before the fix, the list of display devices returned from
>> getDisplayIDs was in the same order as reported by the native system.
>> After your fix the order is reversed. For instance, if previously the
>> main display was always at index [0], not it's always at the tail of
>> the array. This may or may not be a problem for Java applications
>> (likely not a serious problem). However, keeping the same order
>> between Java and native APIs might be a good thing for debugging
>> purposes. Would it be possible to modify the loop at lines 103-106 to
>> preserve the order?
> It is not necessary, because we store them in the Map on java side anyway.

Thanks for the clarification. This part looks fine then.

--
best regards,
Anthony

>>
>> --
>> best regards,
>> Anthony
>>
>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>> After the fix we use screen in sleep state as normal screen, where we
>>> can create new windows, etc.
>>> Disadvantage is that Robot still does not work on such devices.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>
>
>
> --
> Best regards, Sergey.
>

From Sergey.Bylokhov at oracle.com  Wed Mar 19 18:02:59 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Mar 2014 22:02:59 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329D552.90400@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
Message-ID: <5329DBD3.3080202@oracle.com>

On 3/19/14 9:35 PM, Anthony Petrov wrote:
> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>> the new code that you're adding at lines 84-92 might be better
>>> integrated as a separate fix.
>> Before the fix we use CGGetActiveDisplayList, which returns only active
>> device w/o device in sleep or mirror state. The new function
>> CGGetOnlineDisplayList return all of them and we should filter out
>> mirror device.
>
> The specification of CGGetActiveDisplayList suggests that in the case 
> of software mirroring the returned list includes all mirror devices. 
> Therefore I still think that this is a separate bug.
You are right! It seems that on my system always a hardware mirroring is 
used. But I am not sure that it is better to fix it in separate CR. If I 
remove filtering then I'll introduce a new regression for hard 
mirroring. Actually the fix is targeted to fix the problem in graphics 
initialization and it fix that, No?
>
>
>>> 2. Before the fix, the list of display devices returned from
>>> getDisplayIDs was in the same order as reported by the native system.
>>> After your fix the order is reversed. For instance, if previously the
>>> main display was always at index [0], not it's always at the tail of
>>> the array. This may or may not be a problem for Java applications
>>> (likely not a serious problem). However, keeping the same order
>>> between Java and native APIs might be a good thing for debugging
>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>> preserve the order?
>> It is not necessary, because we store them in the Map on java side 
>> anyway.
>
> Thanks for the clarification. This part looks fine then.
>
> -- 
> best regards,
> Anthony
>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk 9.
>>>> After the fix we use screen in sleep state as normal screen, where we
>>>> can create new windows, etc.
>>>> Disadvantage is that Robot still does not work on such devices.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Mar 19 18:43:33 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 19 Mar 2014 22:43:33 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329DBD3.3080202@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
	<5329DBD3.3080202@oracle.com>
Message-ID: <5329E555.5090608@oracle.com>

Why would there be a regression? Displays using hardware mirroring are 
never included in the list by either CGGetActiveDisplayList or 
CGGetOnlineDisplayList. So in this case the results should be the same 
independent from the function used.

Similarly, when using software mirroring, both functions return all the 
mirrored displays. And again, there wouldn't be a regression from just 
using another function.

Please clarify what regression you're talking about.

--
best regards,
Anthony

On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>> the new code that you're adding at lines 84-92 might be better
>>>> integrated as a separate fix.
>>> Before the fix we use CGGetActiveDisplayList, which returns only active
>>> device w/o device in sleep or mirror state. The new function
>>> CGGetOnlineDisplayList return all of them and we should filter out
>>> mirror device.
>>
>> The specification of CGGetActiveDisplayList suggests that in the case
>> of software mirroring the returned list includes all mirror devices.
>> Therefore I still think that this is a separate bug.
> You are right! It seems that on my system always a hardware mirroring is
> used. But I am not sure that it is better to fix it in separate CR. If I
> remove filtering then I'll introduce a new regression for hard
> mirroring. Actually the fix is targeted to fix the problem in graphics
> initialization and it fix that, No?
>>
>>
>>>> 2. Before the fix, the list of display devices returned from
>>>> getDisplayIDs was in the same order as reported by the native system.
>>>> After your fix the order is reversed. For instance, if previously the
>>>> main display was always at index [0], not it's always at the tail of
>>>> the array. This may or may not be a problem for Java applications
>>>> (likely not a serious problem). However, keeping the same order
>>>> between Java and native APIs might be a good thing for debugging
>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>> preserve the order?
>>> It is not necessary, because we store them in the Map on java side
>>> anyway.
>>
>> Thanks for the clarification. This part looks fine then.
>>
>> --
>> best regards,
>> Anthony
>>
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk 9.
>>>>> After the fix we use screen in sleep state as normal screen, where we
>>>>> can create new windows, etc.
>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>
>

From Sergey.Bylokhov at oracle.com  Wed Mar 19 19:29:37 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Mar 2014 23:29:37 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329E555.5090608@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
	<5329DBD3.3080202@oracle.com> <5329E555.5090608@oracle.com>
Message-ID: <5329F021.7020704@oracle.com>

On 3/19/14 10:43 PM, Anthony Petrov wrote:
> Why would there be a regression? Displays using hardware mirroring are 
> never included in the list by either CGGetActiveDisplayList or 
> CGGetOnlineDisplayList. So in this case the results should be the same 
> independent from the function used.
>
> Similarly, when using software mirroring, both functions return all 
> the mirrored displays. And again, there wouldn't be a regression from 
> just using another function.
>
> Please clarify what regression you're talking about.
On my system they return different results. In the mirroring 
CGGetActiveDisplayList returns only 1 device, but CGGetOnlineDisplayList 
returns 2.
>
> -- 
> best regards,
> Anthony
>
> On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
>> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>>> the new code that you're adding at lines 84-92 might be better
>>>>> integrated as a separate fix.
>>>> Before the fix we use CGGetActiveDisplayList, which returns only 
>>>> active
>>>> device w/o device in sleep or mirror state. The new function
>>>> CGGetOnlineDisplayList return all of them and we should filter out
>>>> mirror device.
>>>
>>> The specification of CGGetActiveDisplayList suggests that in the case
>>> of software mirroring the returned list includes all mirror devices.
>>> Therefore I still think that this is a separate bug.
>> You are right! It seems that on my system always a hardware mirroring is
>> used. But I am not sure that it is better to fix it in separate CR. If I
>> remove filtering then I'll introduce a new regression for hard
>> mirroring. Actually the fix is targeted to fix the problem in graphics
>> initialization and it fix that, No?
>>>
>>>
>>>>> 2. Before the fix, the list of display devices returned from
>>>>> getDisplayIDs was in the same order as reported by the native system.
>>>>> After your fix the order is reversed. For instance, if previously the
>>>>> main display was always at index [0], not it's always at the tail of
>>>>> the array. This may or may not be a problem for Java applications
>>>>> (likely not a serious problem). However, keeping the same order
>>>>> between Java and native APIs might be a good thing for debugging
>>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>>> preserve the order?
>>>> It is not necessary, because we store them in the Map on java side
>>>> anyway.
>>>
>>> Thanks for the clarification. This part looks fine then.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk 9.
>>>>>> After the fix we use screen in sleep state as normal screen, 
>>>>>> where we
>>>>>> can create new windows, etc.
>>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>>
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Mar 19 19:34:55 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 19 Mar 2014 23:34:55 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <5329F021.7020704@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
	<5329DBD3.3080202@oracle.com> <5329E555.5090608@oracle.com>
	<5329F021.7020704@oracle.com>
Message-ID: <5329F15F.3030504@oracle.com>

All right, if you say this additional filtering is required for correct 
results and tests confirm that, let it be.

I'm fine with the fix then.

--
best regards,
Anthony

On 3/19/2014 11:29 PM, Sergey Bylokhov wrote:
> On 3/19/14 10:43 PM, Anthony Petrov wrote:
>> Why would there be a regression? Displays using hardware mirroring are
>> never included in the list by either CGGetActiveDisplayList or
>> CGGetOnlineDisplayList. So in this case the results should be the same
>> independent from the function used.
>>
>> Similarly, when using software mirroring, both functions return all
>> the mirrored displays. And again, there wouldn't be a regression from
>> just using another function.
>>
>> Please clarify what regression you're talking about.
> On my system they return different results. In the mirroring
> CGGetActiveDisplayList returns only 1 device, but CGGetOnlineDisplayList
> returns 2.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
>>> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>>>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>>>> the new code that you're adding at lines 84-92 might be better
>>>>>> integrated as a separate fix.
>>>>> Before the fix we use CGGetActiveDisplayList, which returns only
>>>>> active
>>>>> device w/o device in sleep or mirror state. The new function
>>>>> CGGetOnlineDisplayList return all of them and we should filter out
>>>>> mirror device.
>>>>
>>>> The specification of CGGetActiveDisplayList suggests that in the case
>>>> of software mirroring the returned list includes all mirror devices.
>>>> Therefore I still think that this is a separate bug.
>>> You are right! It seems that on my system always a hardware mirroring is
>>> used. But I am not sure that it is better to fix it in separate CR. If I
>>> remove filtering then I'll introduce a new regression for hard
>>> mirroring. Actually the fix is targeted to fix the problem in graphics
>>> initialization and it fix that, No?
>>>>
>>>>
>>>>>> 2. Before the fix, the list of display devices returned from
>>>>>> getDisplayIDs was in the same order as reported by the native system.
>>>>>> After your fix the order is reversed. For instance, if previously the
>>>>>> main display was always at index [0], not it's always at the tail of
>>>>>> the array. This may or may not be a problem for Java applications
>>>>>> (likely not a serious problem). However, keeping the same order
>>>>>> between Java and native APIs might be a good thing for debugging
>>>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>>>> preserve the order?
>>>>> It is not necessary, because we store them in the Map on java side
>>>>> anyway.
>>>>
>>>> Thanks for the clarification. This part looks fine then.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>>>> Hello.
>>>>>>> Please review the fix for jdk 9.
>>>>>>> After the fix we use screen in sleep state as normal screen,
>>>>>>> where we
>>>>>>> can create new windows, etc.
>>>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>>
>>>
>>>
>
>

From petr.pchelko at oracle.com  Wed Mar 19 19:50:41 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 19 Mar 2014 23:50:41 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC on
	Mac with monitor sleeping
In-Reply-To: <5329F15F.3030504@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
	<5329DBD3.3080202@oracle.com> <5329E555.5090608@oracle.com>
	<5329F021.7020704@oracle.com> <5329F15F.3030504@oracle.com>
Message-ID: <3FF51F65-86F4-4E5B-AA7F-4BCA23A03BD6@oracle.com>

Hello, Sergey.

After Anthony have asked all the possible questions I?m left with the only option:
The fix looks good to me.

BTW: I see that there?s one more bug in this method: https://bugs.openjdk.java.net/browse/JDK-8036927 Is it also resolved by this fix?

With best regards. Petr.

19 ????? 2014 ?., ? 11:34 ????? ???????, Anthony Petrov <anthony.petrov at oracle.com> ???????(?):

> All right, if you say this additional filtering is required for correct results and tests confirm that, let it be.
> 
> I'm fine with the fix then.
> 
> --
> best regards,
> Anthony
> 
> On 3/19/2014 11:29 PM, Sergey Bylokhov wrote:
>> On 3/19/14 10:43 PM, Anthony Petrov wrote:
>>> Why would there be a regression? Displays using hardware mirroring are
>>> never included in the list by either CGGetActiveDisplayList or
>>> CGGetOnlineDisplayList. So in this case the results should be the same
>>> independent from the function used.
>>> 
>>> Similarly, when using software mirroring, both functions return all
>>> the mirrored displays. And again, there wouldn't be a regression from
>>> just using another function.
>>> 
>>> Please clarify what regression you're talking about.
>> On my system they return different results. In the mirroring
>> CGGetActiveDisplayList returns only 1 device, but CGGetOnlineDisplayList
>> returns 2.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
>>>> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>>>>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>>>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>>>>> the new code that you're adding at lines 84-92 might be better
>>>>>>> integrated as a separate fix.
>>>>>> Before the fix we use CGGetActiveDisplayList, which returns only
>>>>>> active
>>>>>> device w/o device in sleep or mirror state. The new function
>>>>>> CGGetOnlineDisplayList return all of them and we should filter out
>>>>>> mirror device.
>>>>> 
>>>>> The specification of CGGetActiveDisplayList suggests that in the case
>>>>> of software mirroring the returned list includes all mirror devices.
>>>>> Therefore I still think that this is a separate bug.
>>>> You are right! It seems that on my system always a hardware mirroring is
>>>> used. But I am not sure that it is better to fix it in separate CR. If I
>>>> remove filtering then I'll introduce a new regression for hard
>>>> mirroring. Actually the fix is targeted to fix the problem in graphics
>>>> initialization and it fix that, No?
>>>>> 
>>>>> 
>>>>>>> 2. Before the fix, the list of display devices returned from
>>>>>>> getDisplayIDs was in the same order as reported by the native system.
>>>>>>> After your fix the order is reversed. For instance, if previously the
>>>>>>> main display was always at index [0], not it's always at the tail of
>>>>>>> the array. This may or may not be a problem for Java applications
>>>>>>> (likely not a serious problem). However, keeping the same order
>>>>>>> between Java and native APIs might be a good thing for debugging
>>>>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>>>>> preserve the order?
>>>>>> It is not necessary, because we store them in the Map on java side
>>>>>> anyway.
>>>>> 
>>>>> Thanks for the clarification. This part looks fine then.
>>>>> 
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>> 
>>>>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello.
>>>>>>>> Please review the fix for jdk 9.
>>>>>>>> After the fix we use screen in sleep state as normal screen,
>>>>>>>> where we
>>>>>>>> can create new windows, etc.
>>>>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>>>>> Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>> 
>>>> 
>>>> 
>> 
>> 


From Sergey.Bylokhov at oracle.com  Wed Mar 19 21:51:03 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Mar 2014 01:51:03 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC
	on Mac with monitor sleeping
In-Reply-To: <3FF51F65-86F4-4E5B-AA7F-4BCA23A03BD6@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
	<5329DBD3.3080202@oracle.com> <5329E555.5090608@oracle.com>
	<5329F021.7020704@oracle.com> <5329F15F.3030504@oracle.com>
	<3FF51F65-86F4-4E5B-AA7F-4BCA23A03BD6@oracle.com>
Message-ID: <532A1147.1090800@oracle.com>

On 3/19/14 11:50 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
> After Anthony have asked all the possible questions I?m left with the only option:
> The fix looks good to me.
>
> BTW: I see that there?s one more bug in this method: https://bugs.openjdk.java.net/browse/JDK-8036927 Is it also resolved by this fix?
I hope so, but since I cannot reproduce this issue, I don't want to 
close it right now.
>
> With best regards. Petr.
>
> 19 ????? 2014 ?., ? 11:34 ????? ???????, Anthony Petrov <anthony.petrov at oracle.com> ???????(?):
>
>> All right, if you say this additional filtering is required for correct results and tests confirm that, let it be.
>>
>> I'm fine with the fix then.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 3/19/2014 11:29 PM, Sergey Bylokhov wrote:
>>> On 3/19/14 10:43 PM, Anthony Petrov wrote:
>>>> Why would there be a regression? Displays using hardware mirroring are
>>>> never included in the list by either CGGetActiveDisplayList or
>>>> CGGetOnlineDisplayList. So in this case the results should be the same
>>>> independent from the function used.
>>>>
>>>> Similarly, when using software mirroring, both functions return all
>>>> the mirrored displays. And again, there wouldn't be a regression from
>>>> just using another function.
>>>>
>>>> Please clarify what regression you're talking about.
>>> On my system they return different results. In the mirroring
>>> CGGetActiveDisplayList returns only 1 device, but CGGetOnlineDisplayList
>>> returns 2.
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
>>>>> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>>>>>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>>>>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>>>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>>>>>> the new code that you're adding at lines 84-92 might be better
>>>>>>>> integrated as a separate fix.
>>>>>>> Before the fix we use CGGetActiveDisplayList, which returns only
>>>>>>> active
>>>>>>> device w/o device in sleep or mirror state. The new function
>>>>>>> CGGetOnlineDisplayList return all of them and we should filter out
>>>>>>> mirror device.
>>>>>> The specification of CGGetActiveDisplayList suggests that in the case
>>>>>> of software mirroring the returned list includes all mirror devices.
>>>>>> Therefore I still think that this is a separate bug.
>>>>> You are right! It seems that on my system always a hardware mirroring is
>>>>> used. But I am not sure that it is better to fix it in separate CR. If I
>>>>> remove filtering then I'll introduce a new regression for hard
>>>>> mirroring. Actually the fix is targeted to fix the problem in graphics
>>>>> initialization and it fix that, No?
>>>>>>
>>>>>>>> 2. Before the fix, the list of display devices returned from
>>>>>>>> getDisplayIDs was in the same order as reported by the native system.
>>>>>>>> After your fix the order is reversed. For instance, if previously the
>>>>>>>> main display was always at index [0], not it's always at the tail of
>>>>>>>> the array. This may or may not be a problem for Java applications
>>>>>>>> (likely not a serious problem). However, keeping the same order
>>>>>>>> between Java and native APIs might be a good thing for debugging
>>>>>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>>>>>> preserve the order?
>>>>>>> It is not necessary, because we store them in the Map on java side
>>>>>>> anyway.
>>>>>> Thanks for the clarification. This part looks fine then.
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello.
>>>>>>>>> Please review the fix for jdk 9.
>>>>>>>>> After the fix we use screen in sleep state as normal screen,
>>>>>>>>> where we
>>>>>>>>> can create new windows, etc.
>>>>>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>>>>>> Webrev can be found at:
>>>>>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>
>>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Mar 19 21:52:56 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 20 Mar 2014 01:52:56 +0400
Subject: [9] Review Request: 7124417 [macosx] failure in Window.initGC on
	Mac with monitor sleeping
In-Reply-To: <532A1147.1090800@oracle.com>
References: <5329B75A.7010204@oracle.com> <5329D1F7.5060902@oracle.com>
	<5329D3F6.5040004@oracle.com> <5329D552.90400@oracle.com>
	<5329DBD3.3080202@oracle.com> <5329E555.5090608@oracle.com>
	<5329F021.7020704@oracle.com> <5329F15F.3030504@oracle.com>
	<3FF51F65-86F4-4E5B-AA7F-4BCA23A03BD6@oracle.com>
	<532A1147.1090800@oracle.com>
Message-ID: <26097073-645D-4FA0-AB41-84C52CCD7F55@oracle.com>

It?s 10.9 - specific, so I could check this as soon as I bring a miniDP adaptor home.

With best regards. Petr.

20 ????? 2014 ?., ? 1:51 ?? ???????, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> ???????(?):

> On 3/19/14 11:50 PM, Petr Pchelko wrote:
>> Hello, Sergey.
>> 
>> After Anthony have asked all the possible questions I?m left with the only option:
>> The fix looks good to me.
>> 
>> BTW: I see that there?s one more bug in this method: https://bugs.openjdk.java.net/browse/JDK-8036927 Is it also resolved by this fix?
> I hope so, but since I cannot reproduce this issue, I don't want to close it right now.
>> 
>> With best regards. Petr.
>> 
>> 19 ????? 2014 ?., ? 11:34 ????? ???????, Anthony Petrov <anthony.petrov at oracle.com> ???????(?):
>> 
>>> All right, if you say this additional filtering is required for correct results and tests confirm that, let it be.
>>> 
>>> I'm fine with the fix then.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 3/19/2014 11:29 PM, Sergey Bylokhov wrote:
>>>> On 3/19/14 10:43 PM, Anthony Petrov wrote:
>>>>> Why would there be a regression? Displays using hardware mirroring are
>>>>> never included in the list by either CGGetActiveDisplayList or
>>>>> CGGetOnlineDisplayList. So in this case the results should be the same
>>>>> independent from the function used.
>>>>> 
>>>>> Similarly, when using software mirroring, both functions return all
>>>>> the mirrored displays. And again, there wouldn't be a regression from
>>>>> just using another function.
>>>>> 
>>>>> Please clarify what regression you're talking about.
>>>> On my system they return different results. In the mirroring
>>>> CGGetActiveDisplayList returns only 1 device, but CGGetOnlineDisplayList
>>>> returns 2.
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>> On 3/19/2014 10:02 PM, Sergey Bylokhov wrote:
>>>>>> On 3/19/14 9:35 PM, Anthony Petrov wrote:
>>>>>>> On 3/19/2014 9:29 PM, Sergey Bylokhov wrote:
>>>>>>>> On 3/19/14 9:20 PM, Anthony Petrov wrote:
>>>>>>>>> 1. Previously we didn't exclude mirrored displays from the list. So
>>>>>>>>> the new code that you're adding at lines 84-92 might be better
>>>>>>>>> integrated as a separate fix.
>>>>>>>> Before the fix we use CGGetActiveDisplayList, which returns only
>>>>>>>> active
>>>>>>>> device w/o device in sleep or mirror state. The new function
>>>>>>>> CGGetOnlineDisplayList return all of them and we should filter out
>>>>>>>> mirror device.
>>>>>>> The specification of CGGetActiveDisplayList suggests that in the case
>>>>>>> of software mirroring the returned list includes all mirror devices.
>>>>>>> Therefore I still think that this is a separate bug.
>>>>>> You are right! It seems that on my system always a hardware mirroring is
>>>>>> used. But I am not sure that it is better to fix it in separate CR. If I
>>>>>> remove filtering then I'll introduce a new regression for hard
>>>>>> mirroring. Actually the fix is targeted to fix the problem in graphics
>>>>>> initialization and it fix that, No?
>>>>>>> 
>>>>>>>>> 2. Before the fix, the list of display devices returned from
>>>>>>>>> getDisplayIDs was in the same order as reported by the native system.
>>>>>>>>> After your fix the order is reversed. For instance, if previously the
>>>>>>>>> main display was always at index [0], not it's always at the tail of
>>>>>>>>> the array. This may or may not be a problem for Java applications
>>>>>>>>> (likely not a serious problem). However, keeping the same order
>>>>>>>>> between Java and native APIs might be a good thing for debugging
>>>>>>>>> purposes. Would it be possible to modify the loop at lines 103-106 to
>>>>>>>>> preserve the order?
>>>>>>>> It is not necessary, because we store them in the Map on java side
>>>>>>>> anyway.
>>>>>>> Thanks for the clarification. This part looks fine then.
>>>>>>> 
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>> 
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>> 
>>>>>>>>> On 3/19/2014 7:27 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hello.
>>>>>>>>>> Please review the fix for jdk 9.
>>>>>>>>>> After the fix we use screen in sleep state as normal screen,
>>>>>>>>>> where we
>>>>>>>>>> can create new windows, etc.
>>>>>>>>>> Disadvantage is that Robot still does not work on such devices.
>>>>>>>>>> 
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124417
>>>>>>>>>> Webrev can be found at:
>>>>>>>>>> http://cr.openjdk.java.net/~serb/7124417/webrev.01
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>>> 
>>>>>> 
>>>> 
> 
> 
> -- 
> Best regards, Sergey.


From hs at tagtraum.com  Fri Mar 21 09:36:52 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 21 Mar 2014 10:36:52 +0100
Subject: Checkmark in JCheckBoxMenuItem not HiDPI/Retina capable
In-Reply-To: <73380D5F-A675-439A-B047-56DA46B173F9@tagtraum.com>
References: <8B35AE6B-0E70-4931-998C-13BF06B1EC20@tagtraum.com>
	<52D3BD31.1090109@oracle.com>
	<8E8745F9-2FCF-4850-938B-D03B9BD03F14@tagtraum.com>
	<73380D5F-A675-439A-B047-56DA46B173F9@tagtraum.com>
Message-ID: <11642B0A-FA50-4A97-B71C-D1EAED65B1A9@tagtraum.com>

On Jan 17, 2014, at 13:07, Hendrik Schreiber <hs at tagtraum.com> wrote:

> On Jan 13, 2014, at 12:54, Hendrik Schreiber <hs at tagtraum.com> wrote:
> 
>> Hey Sergey,
>> 
>> bug is filed under "(Bug ID: 9009584 ) - Checkmarks of JCheckBoxMenuItems aren't rendered in high res on Retina"
>> 
>> While at it, you might also want to take a look at "(Bug ID: 9009344 ) - JPopupMenus in Swing don't have rounded corners on OS X".
> 
> Sergey,
> 
> I just realized that sub-menues in JPopupMenus also uses a low res arrow ">". I guess this is part of the same issue.
> Perhaps you want to add a comment to the original bug 9009584...

Hey Guys,

I am very pleased to see that http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8031573 was addressed in JDK8u20-ea.
Unfortunately, at least one icon was (partially) missed - the expand tree control (that little triangle).

It is rendered in HiDPI, when you click on it, but in its regular appearance it is low res.

The problem occurs on OS X 10.9.2 with

java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)


Cheers,

-hendrik


Source code to illustrate the issue - a plain vanilla JTree. Just play with the expansion triangles.

import javax.swing.*;
import java.awt.*;

public class TreeExpanders {

    public static void main(String[] args) {
        final JFrame frame = new JFrame();
        final JTree tree = new JTree();
        frame.getContentPane().setLayout(new BorderLayout());
        frame.getContentPane().add(tree, BorderLayout.CENTER);
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                frame.setBounds(200, 200, 200, 200);
                frame.setVisible(true);
            }
        });
    }
}


From alexandr.scherbatiy at oracle.com  Fri Mar 21 14:40:32 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 21 Mar 2014 18:40:32 +0400
Subject: Checkmark in JCheckBoxMenuItem not HiDPI/Retina capable
In-Reply-To: <11642B0A-FA50-4A97-B71C-D1EAED65B1A9@tagtraum.com>
References: <8B35AE6B-0E70-4931-998C-13BF06B1EC20@tagtraum.com>
	<52D3BD31.1090109@oracle.com>
	<8E8745F9-2FCF-4850-938B-D03B9BD03F14@tagtraum.com>
	<73380D5F-A675-439A-B047-56DA46B173F9@tagtraum.com>
	<11642B0A-FA50-4A97-B71C-D1EAED65B1A9@tagtraum.com>
Message-ID: <532C4F60.6060303@oracle.com>


   Thank you for the report.

   I have created an issue on it: 8038113 [macosx] JTree icon is not 
rendered in high resolution on Retina
      https://bugs.openjdk.java.net/browse/JDK-8038113

   Thanks,
   Alexandr.

On 3/21/2014 1:36 PM, Hendrik Schreiber wrote:
> On Jan 17, 2014, at 13:07, Hendrik Schreiber <hs at tagtraum.com> wrote:
>
>> On Jan 13, 2014, at 12:54, Hendrik Schreiber <hs at tagtraum.com> wrote:
>>
>>> Hey Sergey,
>>>
>>> bug is filed under "(Bug ID: 9009584 ) - Checkmarks of JCheckBoxMenuItems aren't rendered in high res on Retina"
>>>
>>> While at it, you might also want to take a look at "(Bug ID: 9009344 ) - JPopupMenus in Swing don't have rounded corners on OS X".
>> Sergey,
>>
>> I just realized that sub-menues in JPopupMenus also uses a low res arrow ">". I guess this is part of the same issue.
>> Perhaps you want to add a comment to the original bug 9009584...
> Hey Guys,
>
> I am very pleased to see that http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8031573 was addressed in JDK8u20-ea.
> Unfortunately, at least one icon was (partially) missed - the expand tree control (that little triangle).
>
> It is rendered in HiDPI, when you click on it, but in its regular appearance it is low res.
>
> The problem occurs on OS X 10.9.2 with
>
> java version "1.8.0_20-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)
>
>
> Cheers,
>
> -hendrik
>
>
> Source code to illustrate the issue - a plain vanilla JTree. Just play with the expansion triangles.
>
> import javax.swing.*;
> import java.awt.*;
>
> public class TreeExpanders {
>
>      public static void main(String[] args) {
>          final JFrame frame = new JFrame();
>          final JTree tree = new JTree();
>          frame.getContentPane().setLayout(new BorderLayout());
>          frame.getContentPane().add(tree, BorderLayout.CENTER);
>          SwingUtilities.invokeLater(new Runnable() {
>              @Override
>              public void run() {
>                  frame.setBounds(200, 200, 200, 200);
>                  frame.setVisible(true);
>              }
>          });
>      }
> }
>


From hs at tagtraum.com  Fri Mar 21 14:50:21 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 21 Mar 2014 15:50:21 +0100
Subject: Checkmark in JCheckBoxMenuItem not HiDPI/Retina capable
In-Reply-To: <532C4F60.6060303@oracle.com>
References: <8B35AE6B-0E70-4931-998C-13BF06B1EC20@tagtraum.com>
	<52D3BD31.1090109@oracle.com>
	<8E8745F9-2FCF-4850-938B-D03B9BD03F14@tagtraum.com>
	<73380D5F-A675-439A-B047-56DA46B173F9@tagtraum.com>
	<11642B0A-FA50-4A97-B71C-D1EAED65B1A9@tagtraum.com>
	<532C4F60.6060303@oracle.com>
Message-ID: <898578DF-CE10-49E6-8AB9-D6CD387F071D@tagtraum.com>

On Mar 21, 2014, at 15:40, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> 
>  Thank you for the report.
> 
>  I have created an issue on it: 8038113 [macosx] JTree icon is not rendered in high resolution on Retina
>     https://bugs.openjdk.java.net/browse/JDK-8038113
> 
>  Thanks,
>  Alexandr.

Thanks!

-hendrik


From alexandr.scherbatiy at oracle.com  Tue Mar 25 16:10:23 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 25 Mar 2014 20:10:23 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be rendered
	in HiDPI to BufferedImage
Message-ID: <5331AA6F.6030700@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00

   High resolution image width and height were calculated using only 
scale factor in the AquaPainter class.
   The fix calculates image width and height based on the graphics 
transform.

Thanks,
Alexandr.


From Sergey.Bylokhov at oracle.com  Tue Mar 25 16:26:46 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Mar 2014 20:26:46 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5331AA6F.6030700@oracle.com>
References: <5331AA6F.6030700@oracle.com>
Message-ID: <5331AE46.2070609@oracle.com>

Hello, Alexander.
You cannot skip scalfactor as a key, because images with different scale 
are different.

On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>
>   High resolution image width and height were calculated using only 
> scale factor in the AquaPainter class.
>   The fix calculates image width and height based on the graphics 
> transform.
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Mar 26 12:18:01 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 26 Mar 2014 16:18:01 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5331AE46.2070609@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
Message-ID: <5332C579.3010206@oracle.com>


   Hello,

   Could you review the updated fix:
      http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/

    - MultiResolution image is used instead of image width/height scaling
    - Bounds are used in the key instead of the scale factor.


    Thanks,
    Alexandr.

On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
> Hello, Alexander.
> You cannot skip scalfactor as a key, because images with different 
> scale are different.
>
> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>
>>   High resolution image width and height were calculated using only 
>> scale factor in the AquaPainter class.
>>   The fix calculates image width and height based on the graphics 
>> transform.
>>
>> Thanks,
>> Alexandr.
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Mar 26 12:30:21 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 26 Mar 2014 16:30:21 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5332C579.3010206@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com>
Message-ID: <5332C85D.8020907@oracle.com>

Hello, Alexander.
I think it will not work if the user set scale=1.5?

On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>
>   Hello,
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>
>    - MultiResolution image is used instead of image width/height scaling
>    - Bounds are used in the key instead of the scale factor.
>
>
>    Thanks,
>    Alexandr.
>
> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>> Hello, Alexander.
>> You cannot skip scalfactor as a key, because images with different 
>> scale are different.
>>
>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>
>>>   High resolution image width and height were calculated using only 
>>> scale factor in the AquaPainter class.
>>>   The fix calculates image width and height based on the graphics 
>>> transform.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Mar 26 13:43:27 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 26 Mar 2014 17:43:27 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5332C85D.8020907@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com> <5332C85D.8020907@oracle.com>
Message-ID: <5332D97F.10507@oracle.com>


   Could you review the updated fix:
      http://cr.openjdk.java.net/~alexsch/8032667/webrev.02

  The array of sizes is only used for the getResolutionVariants() method.
  The images are scaled according to the mapper function.

   The current fix creates only one size for the resolution variants 
list in case
   if they are not passed to the constructor.

   Thanks,
   Alexandr.

On 3/26/2014 4:30 PM, Sergey Bylokhov wrote:
> Hello, Alexander.
> I think it will not work if the user set scale=1.5?
>
> On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>>
>>   Hello,
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>>
>>    - MultiResolution image is used instead of image width/height scaling
>>    - Bounds are used in the key instead of the scale factor.
>>
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>>> Hello, Alexander.
>>> You cannot skip scalfactor as a key, because images with different 
>>> scale are different.
>>>
>>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>>
>>>>   High resolution image width and height were calculated using only 
>>>> scale factor in the AquaPainter class.
>>>>   The fix calculates image width and height based on the graphics 
>>>> transform.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Mar 26 13:54:00 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 26 Mar 2014 17:54:00 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5332D97F.10507@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com> <5332C85D.8020907@oracle.com>
	<5332D97F.10507@oracle.com>
Message-ID: <5332DBF8.8000305@oracle.com>

Hi, Alexander.
The fix looks fine to me. Probably the test can be automated? before the 
fix COMP->imagex1->imagex2 and the COMP->imagex2 should be the same, and 
after the fix it should be different?

On 3/26/14 5:43 PM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.02
>
>  The array of sizes is only used for the getResolutionVariants() method.
>  The images are scaled according to the mapper function.
>
>   The current fix creates only one size for the resolution variants 
> list in case
>   if they are not passed to the constructor.
>
>   Thanks,
>   Alexandr.
>
> On 3/26/2014 4:30 PM, Sergey Bylokhov wrote:
>> Hello, Alexander.
>> I think it will not work if the user set scale=1.5?
>>
>> On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>>>
>>>   Hello,
>>>
>>>   Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>>>
>>>    - MultiResolution image is used instead of image width/height 
>>> scaling
>>>    - Bounds are used in the key instead of the scale factor.
>>>
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>>>> Hello, Alexander.
>>>> You cannot skip scalfactor as a key, because images with different 
>>>> scale are different.
>>>>
>>>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>>>
>>>>>   High resolution image width and height were calculated using 
>>>>> only scale factor in the AquaPainter class.
>>>>>   The fix calculates image width and height based on the graphics 
>>>>> transform.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Mar 26 14:06:25 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 26 Mar 2014 18:06:25 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5332DBF8.8000305@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com> <5332C85D.8020907@oracle.com>
	<5332D97F.10507@oracle.com> <5332DBF8.8000305@oracle.com>
Message-ID: <728243D7-1415-4699-BA41-523736D3FEE7@oracle.com>

Hello, Alexander.

The fix looks good to me too.

With best regards. Petr.


On 26.03.2014, at 17:54, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Alexander.
> The fix looks fine to me. Probably the test can be automated? before the fix COMP->imagex1->imagex2 and the COMP->imagex2 should be the same, and after the fix it should be different?
> 
> On 3/26/14 5:43 PM, Alexander Scherbatiy wrote:
>> 
>>  Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8032667/webrev.02
>> 
>> The array of sizes is only used for the getResolutionVariants() method.
>> The images are scaled according to the mapper function.
>> 
>>  The current fix creates only one size for the resolution variants list in case
>>  if they are not passed to the constructor.
>> 
>>  Thanks,
>>  Alexandr.
>> 
>> On 3/26/2014 4:30 PM, Sergey Bylokhov wrote:
>>> Hello, Alexander.
>>> I think it will not work if the user set scale=1.5?
>>> 
>>> On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>>>> 
>>>>  Hello,
>>>> 
>>>>  Could you review the updated fix:
>>>>     http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>>>> 
>>>>   - MultiResolution image is used instead of image width/height scaling
>>>>   - Bounds are used in the key instead of the scale factor.
>>>> 
>>>> 
>>>>   Thanks,
>>>>   Alexandr.
>>>> 
>>>> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>>>>> Hello, Alexander.
>>>>> You cannot skip scalfactor as a key, because images with different scale are different.
>>>>> 
>>>>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> Could you review the fix:
>>>>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>>>>  webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>>>> 
>>>>>>  High resolution image width and height were calculated using only scale factor in the AquaPainter class.
>>>>>>  The fix calculates image width and height based on the graphics transform.
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From alexandr.scherbatiy at oracle.com  Wed Mar 26 14:15:26 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 26 Mar 2014 18:15:26 +0400
Subject: [9] Review request for 8038113 [macosx] JTree icon is not rendered
	in high resolution on Retina
Message-ID: <5332E0FE.5090807@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8038113
   webrev: http://cr.openjdk.java.net/~alexsch/8038113/webrev.00

   MultiResolution image is used to create resolution variants for the 
JTree icons.

   The fix assumes that AquaPainter uses the graphics transform for the 
image size calculation
   an so depends on the fix for issue 8032667 [macosx] Components cannot 
be rendered in
http://mail.openjdk.java.net/pipermail/awt-dev/2014-March/007370.html

Thanks,
Alexandr.


From hs at tagtraum.com  Thu Mar 27 09:51:24 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 27 Mar 2014 10:51:24 +0100
Subject: glasspane performance
Message-ID: <39AE38DF-DCAC-41EC-85EA-609B4574242A@tagtraum.com>

Hey..

my application used to use the glasspane for animations, following this simple scheme

- draw initial component state to an image
- draw final component state to an image
- set my own component as glasspane

- the draw the different animation stages in the glasspane component, calling repaint() on the glasspane component with a swing timer

- when the animation is done, re-install the original glasspane

The animation is supposed to last 300ms with 20ms increments. On current laptop hardware running OS X 10.9.2 and JDK 8, I get exactly *no* animation frames. At the same time this works fine on Windows, even running in a Parallels VM on the very same hardware.

Some testing reveals that it's the glasspane's fault. The same animation works (more or less) smoothly, when using a layered pane.
Now, I don't have to use the glasspane (and perhaps I shouldn't), the layered pane works just fine for me. So my initial problem is solved.

But, if I had to use the glasspane, I'd be in trouble. With the current performance, it's fairly unusable.

Looking at the code in JRootPane#setGlassPane(Component), the only thing that sticks out is:

AWTAccessor.getComponentAccessor().setMixingCutoutShape(glass,new Rectangle());

Anyhow. I couldn't find a corresponding bug, so I figured I bring this to your attention. Perhaps this is something you want to investigate further.

Cheers,

-hendrik


From alexandr.scherbatiy at oracle.com  Thu Mar 27 15:49:30 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 27 Mar 2014 19:49:30 +0400
Subject: [9] Review request for 8036882 [macosx] Native memory leak in
	Java_sun_lwawt_macosx_CImage_nativeGetNSImageRepresentationSizes
Message-ID: <5334488A.9080309@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8036882
   webrev: http://cr.openjdk.java.net/~alexsch/8036882/webrev.00

autorelease is added for [[NSMutableArray alloc] init] call.

There is no a test for the fix because it is hard to write it.

Thanks,
Alexandr.


From petr.pchelko at oracle.com  Thu Mar 27 17:37:15 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 27 Mar 2014 21:37:15 +0400
Subject: [9] Review request for 8036882 [macosx] Native memory leak in
	Java_sun_lwawt_macosx_CImage_nativeGetNSImageRepresentationSizes
In-Reply-To: <5334488A.9080309@oracle.com>
References: <5334488A.9080309@oracle.com>
Message-ID: <64AF45FF-419F-402A-BED9-36DB3787A35B@oracle.com>

Hello, Alexander.

The fix looks good to me.

With best regards. Petr.

27 ????? 2014 ?., ? 7:49 ????? ???????, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> ???????(?):

> 
> Hello,
> 
> Could you review the fix:
>  bug: https://bugs.openjdk.java.net/browse/JDK-8036882
>  webrev: http://cr.openjdk.java.net/~alexsch/8036882/webrev.00
> 
> autorelease is added for [[NSMutableArray alloc] init] call.
> 
> There is no a test for the fix because it is hard to write it.
> 
> Thanks,
> Alexandr.
> 


From Sergey.Bylokhov at oracle.com  Thu Mar 27 19:27:01 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Mar 2014 23:27:01 +0400
Subject: [9] Review request for 8036882 [macosx] Native memory leak in
	Java_sun_lwawt_macosx_CImage_nativeGetNSImageRepresentationSizes
In-Reply-To: <64AF45FF-419F-402A-BED9-36DB3787A35B@oracle.com>
References: <5334488A.9080309@oracle.com>
	<64AF45FF-419F-402A-BED9-36DB3787A35B@oracle.com>
Message-ID: <53347B85.9030802@oracle.com>

Hi, Alexander.
The fix looks good to me too.
Thanks.

On 3/27/14 9:37 PM, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> 27 ????? 2014 ?., ? 7:49 ????? ???????, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> ???????(?):
>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8036882
>>   webrev: http://cr.openjdk.java.net/~alexsch/8036882/webrev.00
>>
>> autorelease is added for [[NSMutableArray alloc] init] call.
>>
>> There is no a test for the fix because it is hard to write it.
>>
>> Thanks,
>> Alexandr.
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Fri Mar 28 12:43:18 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 28 Mar 2014 16:43:18 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <5332DBF8.8000305@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com> <5332C85D.8020907@oracle.com>
	<5332D97F.10507@oracle.com> <5332DBF8.8000305@oracle.com>
Message-ID: <53356E66.5040106@oracle.com>


  Hello,

  Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8032667/webrev.03/

  - The automated test which checks that painting a component to 2x 
image and painting the component to 1x -> 2x image gives different result.

   Thanks,
   Alexandr.

On 3/26/2014 5:54 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> The fix looks fine to me. Probably the test can be automated? before 
> the fix COMP->imagex1->imagex2 and the COMP->imagex2 should be the 
> same, and after the fix it should be different?
>
> On 3/26/14 5:43 PM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.02
>>
>>  The array of sizes is only used for the getResolutionVariants() method.
>>  The images are scaled according to the mapper function.
>>
>>   The current fix creates only one size for the resolution variants 
>> list in case
>>   if they are not passed to the constructor.
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 3/26/2014 4:30 PM, Sergey Bylokhov wrote:
>>> Hello, Alexander.
>>> I think it will not work if the user set scale=1.5?
>>>
>>> On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>>>>
>>>>   Hello,
>>>>
>>>>   Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>>>>
>>>>    - MultiResolution image is used instead of image width/height 
>>>> scaling
>>>>    - Bounds are used in the key instead of the scale factor.
>>>>
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>>>>> Hello, Alexander.
>>>>> You cannot skip scalfactor as a key, because images with different 
>>>>> scale are different.
>>>>>
>>>>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix:
>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>>>>
>>>>>>   High resolution image width and height were calculated using 
>>>>>> only scale factor in the AquaPainter class.
>>>>>>   The fix calculates image width and height based on the graphics 
>>>>>> transform.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Mar 28 14:01:47 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 28 Mar 2014 18:01:47 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <53356E66.5040106@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com> <5332C85D.8020907@oracle.com>
	<5332D97F.10507@oracle.com> <5332DBF8.8000305@oracle.com>
	<53356E66.5040106@oracle.com>
Message-ID: <533580CB.501@oracle.com>

Hi, Alexander.
The fix looks good.

On 3/28/14 4:43 PM, Alexander Scherbatiy wrote:
>
>  Hello,
>
>  Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8032667/webrev.03/
>
>  - The automated test which checks that painting a component to 2x 
> image and painting the component to 1x -> 2x image gives different 
> result.
>
>   Thanks,
>   Alexandr.
>
> On 3/26/2014 5:54 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> The fix looks fine to me. Probably the test can be automated? before 
>> the fix COMP->imagex1->imagex2 and the COMP->imagex2 should be the 
>> same, and after the fix it should be different?
>>
>> On 3/26/14 5:43 PM, Alexander Scherbatiy wrote:
>>>
>>>   Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8032667/webrev.02
>>>
>>>  The array of sizes is only used for the getResolutionVariants() 
>>> method.
>>>  The images are scaled according to the mapper function.
>>>
>>>   The current fix creates only one size for the resolution variants 
>>> list in case
>>>   if they are not passed to the constructor.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 3/26/2014 4:30 PM, Sergey Bylokhov wrote:
>>>> Hello, Alexander.
>>>> I think it will not work if the user set scale=1.5?
>>>>
>>>> On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>   Hello,
>>>>>
>>>>>   Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>>>>>
>>>>>    - MultiResolution image is used instead of image width/height 
>>>>> scaling
>>>>>    - Bounds are used in the key instead of the scale factor.
>>>>>
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>
>>>>> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>>>>>> Hello, Alexander.
>>>>>> You cannot skip scalfactor as a key, because images with 
>>>>>> different scale are different.
>>>>>>
>>>>>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix:
>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>>>>>
>>>>>>>   High resolution image width and height were calculated using 
>>>>>>> only scale factor in the AquaPainter class.
>>>>>>>   The fix calculates image width and height based on the 
>>>>>>> graphics transform.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Mar 28 14:12:04 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 28 Mar 2014 18:12:04 +0400
Subject: [9] Review request for 8032667 [macosx] Components cannot be
	rendered in HiDPI to BufferedImage
In-Reply-To: <533580CB.501@oracle.com>
References: <5331AA6F.6030700@oracle.com> <5331AE46.2070609@oracle.com>
	<5332C579.3010206@oracle.com> <5332C85D.8020907@oracle.com>
	<5332D97F.10507@oracle.com> <5332DBF8.8000305@oracle.com>
	<53356E66.5040106@oracle.com> <533580CB.501@oracle.com>
Message-ID: <8BAD9478-25A9-42AE-814D-80D783BB41E4@oracle.com>

Still Looks good.

With best regards. Petr.


On 28.03.2014, at 18:01, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Alexander.
> The fix looks good.
> 
> On 3/28/14 4:43 PM, Alexander Scherbatiy wrote:
>> 
>> Hello,
>> 
>> Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8032667/webrev.03/
>> 
>> - The automated test which checks that painting a component to 2x image and painting the component to 1x -> 2x image gives different result.
>> 
>>  Thanks,
>>  Alexandr.
>> 
>> On 3/26/2014 5:54 PM, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> The fix looks fine to me. Probably the test can be automated? before the fix COMP->imagex1->imagex2 and the COMP->imagex2 should be the same, and after the fix it should be different?
>>> 
>>> On 3/26/14 5:43 PM, Alexander Scherbatiy wrote:
>>>> 
>>>>  Could you review the updated fix:
>>>>     http://cr.openjdk.java.net/~alexsch/8032667/webrev.02
>>>> 
>>>> The array of sizes is only used for the getResolutionVariants() method.
>>>> The images are scaled according to the mapper function.
>>>> 
>>>>  The current fix creates only one size for the resolution variants list in case
>>>>  if they are not passed to the constructor.
>>>> 
>>>>  Thanks,
>>>>  Alexandr.
>>>> 
>>>> On 3/26/2014 4:30 PM, Sergey Bylokhov wrote:
>>>>> Hello, Alexander.
>>>>> I think it will not work if the user set scale=1.5?
>>>>> 
>>>>> On 3/26/14 4:18 PM, Alexander Scherbatiy wrote:
>>>>>> 
>>>>>>  Hello,
>>>>>> 
>>>>>>  Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8032667/webrev.01/
>>>>>> 
>>>>>>   - MultiResolution image is used instead of image width/height scaling
>>>>>>   - Bounds are used in the key instead of the scale factor.
>>>>>> 
>>>>>> 
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>> 
>>>>>> On 3/25/2014 8:26 PM, Sergey Bylokhov wrote:
>>>>>>> Hello, Alexander.
>>>>>>> You cannot skip scalfactor as a key, because images with different scale are different.
>>>>>>> 
>>>>>>> On 3/25/14 8:10 PM, Alexander Scherbatiy wrote:
>>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> Could you review the fix:
>>>>>>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8032667
>>>>>>>>  webrev: http://cr.openjdk.java.net/~alexsch/8032667/webrev.00
>>>>>>>> 
>>>>>>>>  High resolution image width and height were calculated using only scale factor in the AquaPainter class.
>>>>>>>>  The fix calculates image width and height based on the graphics transform.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.
>