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

[Sergey Bylokhov]

On Wed, 27 Apr 2022 15:41:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> We are setting the BICUBIC only in place where we draw the image part of ImageIcon. There is no benefit in pushing this change down the pipeline.
>> 
>> We don't need to push change down to the pipeline, we should push it up to the place where we paint this ImageIcon, eventually where we call ImageIcon.paintIcon()
>> 
>>> It is not a regression, it is a side effect of the JDK-8182043 combined with the Windows 10 update that changed the default windows file icon to the blank white sheet with 1 pixel wide dark gray border.
>>> Because we can not read this icon from the native, when we ask Windows API to provide this icon it ignores the icon size and gives the same 32x32 icon instead. We knew this upfront and the consensus was that we will provide the icon in the MultiResolutionImage and scaling during painting will be good enough to scale it properly. But it is not.
>> 
>> Then why, as described in the JBS, it worked before? Did we request different image, or size, or did we skip scaling?
>
>> We don't need to push change down to the pipeline, we should push it up to the place where we paint this ImageIcon, eventually where we call ImageIcon.paintIcon()
> 
> 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.
> 
>> Then why, as described in the JBS, it worked before? Did we request different image, or size, or did we skip scaling?
> 
> 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.

> On the other hand, @azuev-java demonstrates the problem exists in general: if an icon is scaled down, it may lose relevant details and become white square — it doesn't look good, does it?

Yes, but if we downscale then this is applicable for any other types of icons, or images. If the user render it directly then he can turn on the bicubic option, if we render it ourselves (like in this case) we can provide a solution I referenced above, similar to the text anti-aliasing, when the user may set a special client_property.

But these are two different issues, one of them - specific to MRI and the previous fix where we changed the behavior, and another one - an addition customization of how the Swing renders the images. But before we provide such customization we need to check how slow it will be, in some cases it could be x10(or x1000? I do not remember) times slower.

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

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