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

[Alexey Ivanov]

Hi Sergey,

On 29/09/2017 22:06, Sergey Bylokhov wrote:
> On 9/29/17 07:11, Alexey Ivanov wrote:
>> If I understand correctly, the introduction of the new API does not 
>> change the behaviour in this case, does it?
>>
>> The icon extracted from Windows was 16×16 and will continue to be used.
>> That is the icon will be scaled when painted.
>>
>> To support HiDPI displays the implementation of 
>> |getFileChooser().getFileSystemView().getSystemIcon(f)| should be 
>> enhanced to fetch the icon at the appropriate size according to the 
>> current rendering scale. I mean in standard resolution, get 16×16 
>> icon, for 125% scale factor, get 20×20 icon, for 150% scale factor, 
>> get icon 24×24. (As far as I know, |IExtractIcon::Extract| does not 
>> perform any scaling to account for HiDPI rendering. And it really 
>> can't because different displays can have different DPI settings. 
>> Thus if you request icon size of 16×16, you'll get 16×16 icon, not 
>> 32×32 even if this size is more appropriate to the current HiDPI 
>> scaling.)
>
> Yes, the old getSystemIcon(f) can be enhanced to support MRI and this 
> will fix all its usages. But my point was for a new API and how this 
> new API can solve the problem of access to different dpi icons.
>  - We cannot use FILE_ICON_SMALL because it does not depend from the 
> screen, and it is unclear what the small icons means.
>  - We cannot use FILE_ICON_LARGE by the same reason.
>  - We cannot request some specific size because we know the scale 
> which should be applied to the default icon, but we do not know the 
> size of the default icon.
> So everywhere we should do something like this:
> Icon icon = getSystemIcon(file);
> Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);

I think getSystemIcon(file) could be re-implemented as a call to 
getSystemIcon(file, SMALL_ICON_SIZE * screenScale). The only problem is 
that screenScale is unknown, it cannot be determined in advance, right?

>> Different icon sizes could be combined into MRI lazily.
>> To support it, we could use different APIs to extract the icons. For 
>> example, we can get the list of icon sizes for a file type, and 
>> extract only “native” size. If larger size is required for HiDPI and 
>> the icon has it, then get the larger version and use it for rendering 
>> rather than scaling the one we already have.
>
> It is not necessary to update other parts of the Swing right now, but 
> it should be possible to update it later and use the new API which 
> will be added in this fix, since this fix is a about access to a good 
> quality icons, some comments here:
> https://bugs.openjdk.java.net/browse/JDK-8156183

No, I didn't mean to update other parts. Since Swing operates logical 
coordinates, getting larger icon size from the underlying OS should be 
hidden from user. It could be done via MRI. But to request the right 
physical pixel size of the icon, it's necessary to know the current 
scaling factor in Graphics.

Alternative is to get the entire set from the OS: for example if icon of 
SMALL_ICON_SIZE, i.e. 16×16, is requested, then the getSystemIcon(file) 
returns MRI which contains the following sizes: 16, 20, 24, 32. However, 
it means we'll waste system resources by requesting extra sizes that 
we'll throw away as soon as paint completes. To optimize this solution, 
the API can request only the sizes that correspond to screen DPI. For 
example, if there's only one display in the system, the only one 
(scaled) size is requested; if there are two displays, the returned MRI 
contains physical-sized icons for either display if their DPI settings 
are different.


Regards,
Alexey

>
>>
>> However, it looks to be out of the scope for this particular fix. Yet 
>> this approach will make UI look crispier at higher resolutions.
>
>
>