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

[Alexander Zuev]

Hi Alexey,

   while generally agree i'm not sure that we need to populate ALL of 
the resolutions for every single
icon we request. So my idea that you can see in the new webrev is to 
create the true MRI which will
hold all standatd resolutions within the range of half of requested icon 
size and double of it. That would
cover magnification factors from 50% to 200%. I tested it and the icons 
in the standard JFioleChooser looks
pretty good on display with different magnification factors.

   Here's the new webrev: 
http://cr.openjdk.java.net/~kizune/8182043/webrev.01

/Alex

On 30-May-20 0:35, Alexey Ivanov wrote:
> Hi Alexander, Sergey,
>
> Sorry for my belated reply.
>
> On 08/04/2020 21:32, Sergey Bylokhov wrote:
>> On 4/6/20 10:21 am, Alexander Zuev wrote:
>>> Hi Alexey,
>>>
>>>    i moved method from the new class to the FileSystemView and it 
>>> works, however when
>>> i tried to use it in the JFileManager on Windows i found that 
>>> JFileChooser only uses large
>>> icons in Places tab and with my code icons there are significantly 
>>> worse even on 200%
>>> magnification. They are sharper but the way we scaling them down 
>>> just makes them a
>>> pixelated garbage. You can look at the compare yourself:
>>
>> The old method "FileSystemView.getSystemIcon(File)" as well as 
>> ShellFolder.getIcon(boolean) also
>> uses MRI, and works fine. As far as I understand we should be able to 
>> replace the usage of
>> ShellFolder.getIcon(true) by the new method 
>> FileSystemView.getSystemIcon(File, 32x32). Also we
>> should be able to re-implement FileSystemView.getSystemIcon(File) by 
>> the FileSystemView.getSystemIcon(File, 16x16).
>> And this should not cause any visual regressions, otherwise, we have 
>> some issues in the new method.
>
> I agree.
>
> The new API provides access to larger set of icon sizes rather 16×16 
> and 32×32 only. But I'd expect the same image from new API that was 
> provided via the old API.
>
>>> http://cr.openjdk.java.net/~kizune/8182043/compare/
>>>
>>> Naming is obvious - *old* are the original rendering, *new* is the 
>>> modified with multiresolution image,
>>> number at the end - magnification percent. Yes, the old icons look 
>>> pretty blurry, but are new ones look any better?
>>> Unless we change the way we downscale images in icons any images 
>>> with high details will turn into this i'm afraid.
>>
>> It is not necessary to downscale the image which we fetch from the 
>> native, I guess the reason
>> is that we request the size 256x256 from the native and then downscale?
>
> This is exactly the reason.
>
> JFileChooser requests the 32×32 icon, we get the 256×256 icon and 
> downscale it to 32×32. The result of downscaling cannot be as crisp as 
> manually tuned icon for 32×32.
>
> Can't we always get the requested size from the native?
> This will get the best possible image from the icon resource when the 
> requested size is available in the icon. If not available, the native 
> will scale the icon to the requested size.
>
>>> So i'm proposing making the new method available for user to request 
>>> image of arbitrary size but i don't think using it in
>>> JFileChooser is a good idea. 
>
> Your own test shows the quality of the icon is poor; the new API 
> cannot replace existing one. Why would a user want it then? I propose 
> to pass the requested size to extractIcon() unconditionally.
>
>>> Unless, of course, we create the true multi-resolution image with 
>>> all the resolution variants
>>> rendered by the system - but that is impossible at the moment (as 
>>> Eiric pointed out before) due to the JDK-8212226
>>> not fixed yet - we will have errors on resolution switch or on 
>>> moving of the window between screens with different
>>> magnification factors.
>>
>> Then how the old getSystemIcon(File) and ShellFolder.getIcon(boolean) 
>> work?
>
> I don't quite understand the mechanism but the icons returned change 
> with DPI. This means in HiDPI environment, we get the correctly sized 
> icon to the current DPI.
>
>
> The ultimate goal of this API could be to provide an MRI which stores 
> all the available icon sizes and loads dynamically the size that's 
> most appropriate to the current display settings. Raymond Chen has a 
> blog post about the format of the icon resources [1]. If we do that, 
> we will handle all the scaling ourselves and will be able to define 
> our own algorithm for choosing the closest match. As explained in 
> LookupIconIdFromDirectoryEx [2], LoadIcon and LoadImage “use this 
> function to search the specified resource data for the icon… that best 
> fits the current display device.”
>
>>>
>>> /Alex
>>>
>>> <SNIP>
>
> [1] https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083
> [2] 
> https://docs.microsoft.com/en-ie/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex
>