<Swing Dev> <AWT Dev> [10] Review request for 8182043: Access to Windows Large Icons

[Semyon Sadetsky]

Hi Alexey,


On 10/06/2017 11:42 AM, Alexey Ivanov wrote:
> Hi Semyon, Sergey,
>
> On 30/09/2017 00:08, Semyon Sadetsky wrote:
>> On 9/29/2017 3:15 PM, Sergey Bylokhov wrote:
>>> On 9/29/17 12:39, Semyon Sadetsky wrote:
>>>>>> Why 128 pixels? Windows shell usually provides icons up to 256 
>>>>>> pixels, for example there are 256×256 icons for folders and 
>>>>>> generic file type.
>>>>>
>>>>> It is limitation of our implementation:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151385
>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html
>>>>>
>>>> Sergey, it is not clear how those links are related to the icon 
>>>> size returned by Windows?
>>>
>>> It was a fix where the MAX_ICON_SIZE=128 was added.
>> Actually it limits nothing. We told about the Extract call which may 
>> return any size.
>
> Yes, it does. It limits the size of the returned icon to 128×128.
> I guess if a larger icon is requested, then we'll get a distorted image.
This is artificial limitation when the image is transfered from native 
to java. WinAPI may return bigger images without any issues.
>
>>>>> As far as I understand the bug above, it is possible that OS 
>>>>> returns some other size.
>>>> You've probably didn't understand what Alexey meant. The Extract 
>>>> call may return any size you request (it does scaling internally if 
>>>> there are no suitable image) > But the bug above is about queering 
>>>> the fixed size
>>>> (small or long) which size is determined by OS shell according to 
>>>> the current scale. For those fixed sizes we use SHGetFileInfo not 
>>>> the Extract.
>>>
>>> And every time we will try to make an icon it will be limited to 
>>> 128x128. But it is not critical.
>>>
>>> The issue is that this api, as you said, will depends from some 
>>> general "current scale". which is unrelated to the transform of the 
>>> screen in java.
>>>
>>> If the user will want to use FILE_ICON_LARGE, then to work properly 
>>> he will need to use this code every time in the the paint():
>>> Icon icon = getSystemIcon(file, FILE_ICON_LARGE);
>>> Icon hicon = getSystemIcon(file, 
>>> icon.getIconWidth()*currentScreenScale);
>> This is just wrong. The first line is the correct one for both HiDPI 
>> and nonHiDPI. If you want to have icons like in native apps. For 
>> custom behavior - please use the second line.
>>
>
> Why is it wrong?
> getSystemIcon(file) requests FILE_ICON_SMALL from the OS, then all 
> Java has to paint at any DPI scale is 16×16 icon.
>
> Or am I missing anything?
Sorry, I did not get how is the small icon related to the code above. 
Probably we understood it differently because the explanation is not  
the best. My interpretation is:
For the low DPI screen one should use icon=getSystemIcon(file, 
FILE_ICON_LARGE) when the window is moved to hiDPI screen the 
hicon=getSystemIcon(file, icon.getIconWidth()*currentScreenScale) should 
be used. And this approach is wrong.

The primary purpose of the current fix is to fix the compatibility issue 
we got when we closed shell folder API in 9.
The user code which doesn't work in 9 should not be changed in the way 
proposed by Sergey. This code should be updated to use 
getSystemIcon(file, FILE_ICON_LARGE) instead of closed getIcon(true) and 
getSystemIcon(file, FILE_ICON_SMALL) instead of closed getIcon(false).
The newly written code may use getSystemIcon(file, 
FILE_ICON_LARGE/SMALL) to get the icon in the native platform which 
determines its size at the current DPI (DPI-unaware usage)
or getSystemIcon(file, size) to have any custom size which can be 
multiplied by DPI. I see no reason to use both approaches 
simultaneously  at any circumstances.

--Semyon
>
>
> Regards,
> Alexey