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

Sergey Bylokhov serb at openjdk.java.net
Thu Jun 2 22:12:35 UTC 2022


On Thu, 2 Jun 2022 14:08:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Time: 21313400
> > Time: 4036200
> > Time: 1140613100
> > Time: 839499200
> 
> These are some extreme numbers, on my system it is more like 8 to 10 times slower depending on the run: Time: 13250900 Time: 10126200 Time: 113548000 Time: 113630100

It depends on the native accelerated rendering pipeline implementation, which does not support bicubic and do it in on software loops.

> But still - the question is: how big the difference will be in the real application, knowing that we only apply this hint to a small minority of the cases and difference for single repaint (which is cached and not like we re-draw it continuously) so can we neglect the performance variation to achieve better visual result?

The same question could be asked about all other the icons, why we should upscale/downscale by using the bicubic only the MRI images. The same issue may occur for other icons. For example the FileSystemView.getSystemIcon() may return the icon stored in the "FileView.directoryIcon" UI property. Or the user may create its own image, etc. The reason was about performance. The problem right now is that the user cannot select the "good" appearance if he wants, unlike the text antialiasing. My suggestion is to add a UI property which we discussed above.

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

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



More information about the client-libs-dev mailing list