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

[Alexander Zuev]

On Fri, 3 Jun 2022 05:12:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> > 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?
>>> 
>>> 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.
>> 
>> Where it is specified that the size of the small icon will be the same and the size of the large will grow? Probably it is related to the size property where we did not set the size of the small icon?
>> 
>> I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20
>
>> I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20
> 
> 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.

> But can we use it as a backup if the system does not return the expected size on the initial/current call?

No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.

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

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