RFR: 8282526: Default icon is not painted properly [v4]
Sergey Bylokhov
serb at openjdk.java.net
Wed Jun 1 23:55:20 UTC 2022
On Fri, 27 May 2022 18:02:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:
>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>
> Use small icon pointer for icons less than 24 pixels wide - this way we
> get the 16x16 icon which is better for scaling purposes.
src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 987:
> 985: size = 16;
> 986: }
> 987: hres = pIcon->Extract(szBuf, index, &hIcon, &hIconSmall, size);
Looking into this change I assume that the reason why the windows "ignores" the requested size of 16x16 was that we request the size 16x16 but after that used the large icon only which is 32x32 by default, is it correct?
The last parameter of [this](https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method:
>nIconSize
The desired size of the icon, in pixels. The low word contains the size of the large icon, and the high word contains the size of the small icon. The size specified can be the width or height. The width of an icon always equals its height.
Do we need to update the size value and take into account the low/hi sizes?
src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 993:
> 991: } else {
> 992: fn_DestroyIcon((HICON)hIconSmall);
> 993: }
Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?
Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7805
More information about the client-libs-dev
mailing list