On Thu, 9 Jun 2022 09:52:42 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>>> 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. > > 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? We don't request proper size, we always request a list of size. If 16×16 icon is requested, then 20×20 up to 16*2 = 32. https://github.com/openjdk/jdk/blob/7f52c50ba32eecf5f379f8db30ac6a5cc50b3b66/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1150-L1151 Such MRI handles scales from 1.0 to 2.0. Maybe we should increase the list to 3.0, some Windows laptop default to 300%. ------------- PR: https://git.openjdk.org/jdk/pull/7805
