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.
