On 9/26/17 14:37, Semyon Sadetsky wrote:
This means that on HiDPI screen the FILE_ICON_LARGE works in similar
way as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the
FILE_ICON_SMALL on HiDPI is unclear, because it is half of the correct
size.
Small and large don't have any special meanings for HiDPI. They are some
conditional sizes established by the native platform for the current
screen resolution.
The question what is the current screens resolution when you have two
screens?
Why is it half of the correct size? It is the same size as for non-HiDPI
and that is the correct size because otherwise java UI component that is
HiDPI unaware would paint icons 2 times bigger in size than it is
required. But the resolution of small/large icons may differs in case of
HiDPI because it is determined by the size of the images returned by the
native platform by the small/large icon queries.
It is half of the correct size because on HiDPI it is better to use
hidpi icons instead of lowdpi. Will the HiDPI unaware apps draw x2 icons
correctly or not depends from our implementation. If we will return the
MRI then it will be drawn in correct size even if the bigger(HiDPI)
image will be used.
For example one of the consumer of this new API is WindowsFileView.
How the code below should be changed to work on a different screens,
and request the proper icon?
WindowsFileChooserUI.java
1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);
Why it should be changed? The code is requesting the proper icon.
Because this method returns an icon of 16x16 pixels, which will be
rescaled to 32x32 pixels in paint operation.
--
Best regards, Sergey.
