<AWT Dev> RFR: 8182043 Access to Windows Large Icons

[Alexey Ivanov]

On 18/06/2020 02:30, Sergey Bylokhov wrote:
> On 6/17/20 5:50 pm, Sergey Bylokhov wrote:
>
>> I guess it is too early to compare behavior before and after the fix 
>> since the fix has a few bugs.
>>   - It does not fetch several sizes, as it was expected from the 
>> code, but load only one native size
>> and map it to the different resolutions.

Yes, I re-read your message and found this mistake.
I fixed it locally.

Then I noticed JFileChooser does not really use the new method which 
returns MRI, so this explains why JFileChooser never adjusts the icons 
according the screen DPI.

I modified Win32ShellFolder2.getIcon(boolean) to use getIcon(size) 
instead of getIcon(getAbsolutePath(), getLargeIcon), and now the file 
icons are updated when JFileChooser window is moved from standard DPI 
monitor to a High DPI one (150%) and back. I noticed one artefact 
though: the customised icons from disk drives disappeared, some file 
icons look clipped, on either monitor.

>>   - It reverts part of the JDK-8151385, and as far as I understand 
>> the bug described in
>>     8151385 starts to reproduce.

I couldn't reproduce it. The icon seems to be wrapped into 
MultiResolutionIconImage.

>>
>> BTW I think the best possible fix is to load all actually existed 
>> icons into the MRI:
>>   - The user will be able to use any of these icons via 
>> MRI.getResolutionVariants()
>>   - And it solves all problems related to HiDPI.

Wouldn't it be a waste of memory?
If the app or JFileChooser shows only 16×16 icon, especially in the 
environment with only one monitor and standard DPI, loading the entire 
set will take some memory. It could also reduce the speed of showing the 
JFileChooser interface.

>> But the open question is it possible to "load all actually existed 
>> icons" or not.

I believe it's possible. But we'll have to use different API.

>
> And if that's not possible then we need to investigate different 
> possible approaches.
>  - Returning exact icon as the user requested

This was the initial approach.

>  - Returning some predefined array of icons
>  - Returning some predefined MRI.

This is how it's implemented in webrev.01 by Alexander.

>  - Load all the icons at once
>  - Load icons on the fly when the rendering are occurring
> etc.
>

Loading icons on the fly seems the most memory-effective way.

In general, I like Alexander's current approach.


Regards,
Alexey