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

[Sergey Bylokhov]

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);


> 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

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



-- 
Best regards, Sergey.