RFR: 8282526: Default icon is not painted properly [v3]
Sergey Bylokhov
serb at openjdk.java.net
Fri Apr 29 00:26:44 UTC 2022
On Wed, 27 Apr 2022 15:41:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:
> Why? As i shown in the test case the problem affects any ImageIcon based on the MultiResolutionImage. I'm not trying to solve the singular issue that in the Windows LaF - i am trying to eliminate the reason this problem can show up.
Default interpolation for all rendering in java2d is NN, if the user wants he may change it to any other modes. This is consistent for all types of images, and MultiResolutionImage is not any special. In this particular case the code where we call ImageIcon.paintIcon() may set different interpolation when some system property is set, similar to the [antialiasing](https://github.com/openjdk/jdk/blob/d5dacffaee5a3626e7c9994b5d24f9514926e40c/jdk/src/java.desktop/share/classes/sun/swing/SwingUtilities2.java#L480). But it is not so important since the root cause below.
> Because before that change we were using different binary API to retrieve icons. This API only allows gathering 8x8 and 16x16 icons. The new API can be used for requesting icons of any size but for some files it ignores the requested size and only returns 32x32 icon. In this case we creating the multi resolution image with that icon inside and allow icon painting routine do the scaling. As i shown in my test for this bug the scaling works poorly and here i'm trying to enhance it. Can it be done in WinLAF? Yes, absolutely, but it will not solve the more generic issue.
So this is the actual root cause of the problem: the change in behavior of the FileSystemView.getSystemIcon() caused by using a different API that ignores the passed size. Since the size 16x16 is the default size for getSystemIcon() it would be good to restore the old behavior(mix the new and old) and request the best resolution from the system. It will save some memory and provide the best performance.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7805
More information about the client-libs-dev
mailing list