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.
