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

[Alexey Ivanov]

On Fri, 2 Oct 2020 23:29:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @aivanov-jdk Can you review this?
>
> I still suggest to try the approach recommended here:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016074.html
> 
> On 29.05.2020 14:35, Alexey Ivanov wrote:
>> 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.”> [1] https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083 [2]
>> https://docs.microsoft.com/en-ie/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex
> 
> If an approach above works then we could request the icon of the exact existed size, and if that size is unknown we
> could request some predefined size like 16,24. etc
> Some additional comment was sent here:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016081.html

> I still suggest to try the approach recommended here:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016074.html
> 
> If an approach above works then we could request the icon of the exact existed size, and if that size is unknown we
> could request some predefined size like 16,24. etc

I agree that using `LookupIconIdFromDirectoryEx` would allow us to load only the sizes that are available in the icon
resource rather than loading a pre-defined set of sizes, some of which may be missing and thus will be scaled by
Windows.

On the other hand, I think the current approach is good enough. It provides access to larger set of icons and improves
`JFileChooser` support for High DPI environments. However, there's still room for improvement and for unification of
the way the icons are requested from the system: at this time, there are two similar functions which use different APIs.

I'd like to comment on this part from previous discussion:
https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016080.html
> On 8/30/2020 12:41 PM, Sergey Bylokhov wrote:
> > On 30.08.2020 11:49, Alexander Zuev wrote:
> > > I did tried that approach and haven't found any benefits over the one
> > > i used in the fix -
> > > it is neither faster nor more accurate.
> >
> > How it could be less accurate if it allows us to read the icon of the
> > exact size, instead of some predefined size in our code
> > (16, 24, 32, 48, 64, 72, 96, 128, 256)?
> > As far as I understand If the file has only an icon of size 100,100 we
> > will never return this one icon, but instead will build the list of icons.
>
> For once i haven't seen any resource that contains a 100x100 icon, but
> yes - in this case we will ask OS to interpolate icon into sizes we know
> of and will return a set of sizes.

I'd rather agree that no icon contains 100×100 size only. Yet it's pretty common that some sizes are not available in
the icon resource. So the assumption that all of these sizes are available is wrong.

> As for less accurate - i mean that in most cases (in all cases i observed
> actually) OS doing much better job interpolating icons than we do.

Yet if the requested size differs from the above set, the icon will be scaled twice: by the OS and then by Java. In
such a case, the result of scaling the original icon will likely be better than scaling an already scaled icon.

> Plus it only works when we can get the location of the file containing
> this resource and we will still have to implement a fallback
> method when system says that path to resource file can not be resolved.

And I am still wondering why it happens. I can imagine a situation where an icon for a file is generated on the fly by
the `IExtractIcon`, yet it's pretty uncommon.

The usage of different APIs can be the reason why drives lost their customised icons.


As for the additional comment:
> Some additional comment was sent here:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016081.html

It talks about tray icons. It depends on the way the icon is extracted, and to support High DPI environment, the icon
must be an MRI. So I'd say the comment is not strictly relevant to the current discussion. However, this new
implementation may improve the display of tray icons too if this new API is used to get the icon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/380