On Tue, 26 Apr 2022 22:46:47 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> Fixing it in the ImageIcon is similar to fixing it by changing internal > default state of the rendering pipeline in any other places like > images/graphics/fonts, while we have to change that state "externally". We > have to set BICUBIC interpolation in the place where we draw that image/icon. 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. > But before discussing that, it would be good to understand: > > * is it a regression or not, if yes then what change caused that, did we > have some wrong assumption? 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. > * why we need to downscale the image, 16x16/32x32 is quite common sizes > why we cannot read an exact size from the native which I think will provide > the best quality? 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. The default scale algorithm is terrible and when new icons appeared it became obvious. Aside of that default scaling on fractional magnification factors such as 5/8 or 7/8 looks just bad - a lot of scaling artifacts and missing details. That has to be addressed and that's what i'm trying to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/7805
