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

[Sergey Bylokhov]

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.