[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 8282526: Default icon is not painted properly [v4]
From:       Alexander Zuev <kizune () openjdk ! java ! net>
Date:       2022-05-27 18:16:42
Message-ID: 8vrDNTJTPocLihty5ZMoBaqGEX23B4gXxis8TtBvuZ8=.5700255b-33a0-4b17-bbb2-523f5a19e9c8 () github ! com
[Download RAW message or body]

On Fri, 27 May 2022 18:02:51 GMT, Alexander Zuev <kizune@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.

I have fixed the 16x16 icon generation on Windows, but this will not help the generic \
problem that i demonstrated with the test case, on the magnification factors like \
125% or 175% without the proposed fix for the ImageIcon the result looks trashy - \
jagged lines, missing details. I have done testing with the modified regression test \
case to see how my change affects performance. Notice that this is the worst case \
scenario, when all of the paintings trigger the fix (which is only triggered for \
MultiResolutionImage based icons and only when this MRI does not have the exact match \
for the requested resolution and scaling is required - this is like 0.01% of overall \
cases because for majority of image icons they are either single image based or MRI \
has the variant requested ready for display. And even in this worst case scenario on \
1000 iterations test does not show any difference. On 10000 iterations the difference \
is measurable in tens of milliseconds between test runs. On 100000 iterati  ons test \
execution with BICUBIC approximation is noticeable (like test run takes more than a \
second longer).

We can limit the maximum size of icon we process by some reasonable number, like do \
not process icons bigger than 256 pixel wide or high so we do not cause any \
noticeable slowdown, but i still think this needs to be done - otherwise on these odd \
magnifications we look nothing alike the native applications (windows looks like \
using some sort of bicubic interpolation for their icons) and just plain bad.

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

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


[prev in list] [next in list] [prev in thread] [next in thread]