RFR: 8282526: Default icon is not painted properly [v4]

[Alexey Ivanov]

On Fri, 3 Jun 2022 21:48:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.
>> 
>> How do we request the proper size for the example above when the scale is 1.25 and the "small" image? The requested size should be 20x20 but we will request 16x16 or 32x32 and then upscale/downscale, no?
>
>> No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.
> 
> Are you sure? That article said the opposite and suggest to use SHDefExtractIcon if the simple extract fails. Probably we should recheck why it does not work for your old testing it seems this should be even faster since it read only one image instead of small+large.

> > Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
> 
> No, during initial implementation i tried it and it worked even worse and less stable.

I can't remember `SHDefExtractIcon` was even tried. According to the documentation for `IExtractIconW::Extract` and to [the article](https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103), another method is to be used when `IExtractIconW::Extract` returns `S_FALSE`.

Previously, [we discussed](https://github.com/openjdk/jdk/pull/380#issuecomment-702999573) Raymond Chen's post [The format of icon resources](https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083) and [`LookupIconIdFromDirectoryEx`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex) function.

> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.

I must admit I still don't like this approach much, we extract 16×16 icon even when we don't need it.

Is it better to request small icon only when the size is less than 32?

I think it makes sense to submit a bug to explore using `LookupIconIdFromDirectoryEx` to extract icons so that we have the set of icons which is provided provided in the resources and avoid getting scaled icons. There should be another bug to add fallback to using `SHDefExtractIcon` for the case where `IExtractIconW::Extract` returns `S_FALSE`.

These are separate issues from the icon rendering, even though icon extraction issues revealed the problem with rendering, scaling up/down the icons to be specific.

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

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