RFR: 8282526: Default icon is not painted properly

[Jeremy]

On Mon, 14 Mar 2022 02:29:47 GMT, Jeremy <duke at openjdk.java.net> 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.
>
> test/jdk/javax/swing/ImageIcon/MultiResolutionImageIcon.java line 127:
> 
>> 125:         return null;
>> 126:     }
>> 127: }
> 
> This test reads a little strange to me. (I'm not an official openjdk reviewer, though, so feel free to disregard.)
> 
> If I run this test with the existing ImageIcon class it creates an image that resembles:
> ![image](https://user-images.githubusercontent.com/7669569/158093894-be7a73c6-6936-4725-bb09-cd054a2dccc2.png)
> 
> If I run this test with the revised code it creates an image that resembles:
> ![image](https://user-images.githubusercontent.com/7669569/158093939-bffc62c7-7a5c-4b0e-b71e-710c5049daf6.png)
> 
> Based on the changes in ImageIcon: I only expected to see changes related to rendering hints. (That is: I expected to see differences in antialiasing and scaling artifacts.)
> 
> Would you mind if I proposed a different test?

Ah, I figured out part of my confusion:

In my case (my primary monitor was set to 100% resolution): the ImageIcon we get back uses a BufferedImage that is 16x16. So when it is displayed on a 150% monitor it has to scale *up*.

Depending on your monitor resolution: you might start at a 32x32 BufferedImage that is scaling down. Or you might not have a BufferedImage at all: you might have their custom MultiResolutionIconImage (which is backed by a BufferedImage).

So all that is to say: I misunderstood the original code's design. And now it sounds like there a lot of separate convos here, so I'll make this my last comment unless someone wants to follow-up with anything.

Additional context/feedback:

The image in question is coming from Win32ShellFolder2#makeIcon(..)


<init>:315, BufferedImage (java.awt.image)
makeIcon:1020, Win32ShellFolder2 (sun.awt.shell)
call:1066, Win32ShellFolder2$15 (sun.awt.shell)
call:1039, Win32ShellFolder2$15 (sun.awt.shell)
run$$$capture:264, FutureTask (java.util.concurrent)
run:-1, FutureTask (java.util.concurrent)
 - Async stack trace
<init>:132, FutureTask (java.util.concurrent)
newTaskFor:108, AbstractExecutorService (java.util.concurrent)
submit:139, AbstractExecutorService (java.util.concurrent)
invoke:621, Win32ShellFolderManager2$ComInvoker (sun.awt.shell)
invoke:519, ShellFolder (sun.awt.shell)
invoke:505, ShellFolder (sun.awt.shell)
getIcon:1039, Win32ShellFolder2 (sun.awt.shell)
getSystemIcon:249, FileSystemView (javax.swing.filechooser)
main:19, SwingDemo


If we wanted to apply a resolution somewhere other than the ImageIcon class:

We could instead change makeIcon() to return a custom MultiResolutionImage that always applies interpolation. Here's a variation of the original bug's app that models this idea:

https://docs.google.com/document/d/1fcXJ9g6uTTZZlIt1BfzNFg2-Hs05CCpNRjyG1FnXKns/edit?usp=sharing

I could spin this up as a PR or discuss this further if requested. I'm not saying it's necessarily better; I'm just brainstorming other approaches.

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

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