<AWT Dev>  Review request for 8148619: Select the closest resolution variant in BaseMultiResolutionImage
semyon.sadetsky at oracle.com
Fri Sep 8 18:48:53 UTC 2017
On 09/08/2017 11:29 AM, Sergey Bylokhov wrote:
> This is not a mistake, it was done intentionally because this is a
> small/basic/simple/fast implementation.
This is important criteria but it is not enough for public API. In
internal classes the internal implementation logic could be shared
between the provider class and its client, but this obviously violates
the encapsulation concept. But this is not suitable for a public API.
Look at the way how this API is designed: To have
BaseMultiResolutionImage woking correctly the client must provide
BaseMultiResolutionImage internal data structure prepared by a certain
rule in constructor argument. This API design looks inappropriate to
common standard without any significant reason.
> On 9/8/17 11:06, Semyon Sadetsky wrote:
>> 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
>>> 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:
>>>> 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
More information about the awt-dev