On 10/6/17 13:01, Semyon Sadetsky wrote:
On 10/06/2017 12:38 PM, Sergey Bylokhov wrote:
On 10/6/17 09:53, Alexey Ivanov wrote:
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
I see. And it can be changed, if deemed necessary, can't it?
Yes we can.
Since you were the person who approved this fix can you explain why the
limitation was introduced?
We can decide whether this limitation should be reverted in a separate bug.
The maximum icon which we use is 32pixel's icon, and 128 is a size of
this icon on 4k monitor.
As far as I understand the bug above, it is possible that OS returns
some other size.
No, it is not.
In that bug icons are extracted from Image List which is created a
part of Toolbar:
1036 HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, NULL,
Then an icon is extracted from that image list.
Obviously, Toolbar can create and creates, as the bug report shows,
its icon set of different size depending on the current DPI setting,
or rather the DPI settings of the main display.
As for JOptionPane, the icons are loaded using ::LoadIcon which loads
icon of the default size only. Depending on the current DPI setting,
it may return icon of larger size.
Yet in this fix, the file icon is requested with explicit size. You
will get the size you requested.
Probably we have some other bug in the fix, but unfortunately I cannot
confirm behavior you describe. For example if I request the icon for
some pdf,java.txt files of size 100m then:
- On HiDPI screen I get the native icon of size 64.
- On LowDPI screen I get the native icon of size 32.
In both cases the user will get MRI, which will scale the native icon.
--
Best regards, Sergey.
