<AWT Dev> [10] Review request for 8148619: Select the closest resolution variant in BaseMultiResolutionImage

[Semyon Sadetsky]

Hi Sergey,

On 09/07/2017 01:41 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
>
> The responsibility for sorting of an array was intentionally moved to 
> the user, because the getResolutionVariant method () is called in each 
> draw of the image. For this purpose in documentation for a class and 
> in a documentation for constructors it was specified that the array 
> shall be sorted. It is the reason why the bug of JDK-8147849 was closed.
This seems to me a mistake in the API design which this update is trying 
to fix. Since we opened this API for everybody's use the base 
implementation of the MultiResolutionImage  should  be covering its most 
frequent and general usage. And in this general usage the appropriate 
resolution among the provided image variants should be chosen at the 
time the MR image is drawn. This is the logic we use internally in JDK 
to draw icons and other UI stuff on the HiDPI display and it is in 
demand for user applications in most cases.
When a predefined order of the image variant selection is required then 
getResolutionVariant() may be overridden to achieve that. But obviously 
this is a rare case and it shouldn't be a basic implementation.

--Semyon
>
> RFE which you try to fix cover another use-case:
> If the user will use the sorted array  [@1 , at 20] then we should select 
> @1 if "-Dsun.java2d.uiScale=2" is used but not @20
>
> On 9/6/17 19:31, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8148619
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/
>>
>> The algorithm selecting the best resolution variant of the 
>> BaseMultiResolutionImage was updated to be insensitive to the order 
>> of image variants in the initially provided array.
>>
>> The BaseMultiResolutionImage specification was updated correspondingly.
>>
>> --Semyon
>>
>
>