[9] Review request for 8032667 [macosx] Components cannot be rendered in HiDPI to BufferedImage

[Sergey Bylokhov]

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.