Hi, Alexander.

A few initial question before I have look to the webrev:

 - Why we need a new class for only one method, why we cannot enhance the 
FileSystemView
   where the similar method is implemented already getSystemIcon(File)?
 - Can we try to re-implement the places where the old method 
ShellFolder.getIcon(boolean)
   was used, and change it to use the new public API, just to confirm that our 
new code is a
   a good replacement of the old/private api. I guess we could get rid the 
boolean version.
 - The current spec for SystemIcon.getSystemIcon() specify that the icon will 
store the
   "maximum quality icon" what does it meant?
 - Another question is about multi-screen environment, if the JFileChooser will 
be shown
   on the non-HiDPI screen and then moved to the HiDPI screen which icons we 
will request
   from the native and which actual icons(resolution) will we draw on each 
screen?(both types
   of icons large/small are interesting).

On 3/30/20 4:19 am, Alexander Zuev wrote:
Hello,

   please review my fix for the issue 8182043: Access to Windows Large Icons

   Bug: https://bugs.openjdk.java.net/browse/JDK-8182043
   Webrev: http://cr.openjdk.java.net/~kizune/8182043/webrev 
<http://cr.openjdk.java.net/~kizune/8182043/webrev/>

   Main idea is to provide a new API call to retrieve image of the specified 
size
and to make Windows implementation that for all the resolutions higher than 24 
pixels
returns the multi resolution image icon with image inside being the highest 
quality icon
available and the size set to the size requested by the user. This way we will 
have good
scaling across the different resolution while maintaining relative sizes in the 
UI intact.
The exception made for images size of 24 and less since sometimes application 
has
different image for the small icons in its resource section which is optimized 
to
make sure that on low resolution screen this icon is not displayed as just 
scaled down
blurry little square.

/Alex


--
Best regards, Sergey.

Reply via email to