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

[Alexander Zuev]

Alexey, Sergey,

   here's the latest version of the fix:

http://cr.openjdk.java.net/~kizune/8182043/webrev.02/

It adds one more native method - hiResIconAvailable
that queries if system will be able to provide high resolution icons for 
a given file.
Now i have tested three approaches with the FileManager:
The old one - at magnification 150% can be seen here:
http://cr.openjdk.java.net/~kizune/8182043/example/fchooser_old_150.PNG
I changed the behavior by making the icon loaded by the FileChooser a 
MultiResolutionIcon
carrying both small and large icons at the same time.
The result looks much better - here's the same view with the 
intermediate fix:
http://cr.openjdk.java.net/~kizune/8182043/example/fchooser_inter_150.PNG
But then i added the new native method and in FileChooser i'm getting 
the multiResolutionIcon
for all the files for which it is possible. The result looks much crisper:
http://cr.openjdk.java.net/~kizune/8182043/example/fchooser_new_150.PNG
But there's one catch: new way of retrieving icons does not get the 
custom drive
icon (can be seen at disk C: - the windows logo identifying the windows 
system drive
is no longer present). I am questioning myself, what is better: to have 
better icon quality
and missing custom disk logo or to have custom disk logo and mediocre 
icon quality?

/Alex


On 22-Jun-20 11:27, Alexander Zuev wrote:
> Hi Alexey,
>
>   sorry for late responce, after fixing that initial error with the wrong
> icon sizes pulled i found a lot of corner cases that needed some 
> additional digging.
>
> On 18-Jun-20 20:56, Alexey Ivanov wrote:
>> 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.
> I also noticed this behavior, some icons retrieved with the 
> extractIcon method got clipped or improperly scaled.
> I tried to dig deeper and found that it happens when 
> pIcon->GetIconLocation function returns "*"
> as location of the resource file. I haven't found exact reason for 
> that but when this is the case then
> getIconBits function always retrieves 32x32 icon no matter what icon 
> size we requested.
> We then scale it down to 16x16 and the result is unpleasant.
> I'm trying to find another way of retrieving the custom icon but for 
> now i would say that
> for the small icons the approach of getIcon function which uses 
> SHGetFileInfo holds better results.
>
> So far the approach that seems to be working is to check if we have a 
> high resolution
> icon available by requesting icon location. If icon location is not 
> known we can get both
> low and high resolution icons from SHGetFileInfo and store them in the 
> MRI. If high res icon available
> then fetch all the standard resolution icons and also return them as MRI.
>
> /Alex