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.
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.
