<AWT Dev> RFR: 8182043 Access to Windows Large Icons

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Mar 31 02:16:44 UTC 2020

On 3/30/20 5:02 pm, Alexander Zuev wrote:
>>  - Why we need a new class for only one method, why we cannot enhance the FileSystemView
>>    where the similar method is implemented already getSystemIcon(File)?
> As you know this is not the first attempt to fix this issue and when i asked about "Why do we need
> a separate class for one new method" the answer was "There is a reason, we tried different approaches
> and this one is what we ended up with". Exact reason buried somewhere in the previous reviews.
> Personally for me i would prefer adding the new method to some existing public class.
> Here's the link to the latest bit of the discussion that i found and there was exactly the same question
> raised by Alexey Ivanov, there are some reasons for creating a separate class:
> http://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014941.html

If that the only reason, when I think we can get rid it.

>>  - Can we try to re-implement the places where the old method ShellFolder.getIcon(boolean)
>>    was used, and change it to use the new public API, just to confirm that our new code is a
>>    a good replacement of the old/private api. I guess we could get rid the boolean version.
> It is outside of the initial scope of the request but yes - i can do it. Should i do it within this fix or
> should i create a new bug and do it there?

Such change will show how well the new API can be used instead of getIcon(boolean),
this one of the things the bug reporter wanted to achieve.

>>  - The current spec for SystemIcon.getSystemIcon() specify that the icon will store the
>>    "maximum quality icon" what does it meant?
> It means that the maximum size of the icon allowed by the system will be used. Right now on
> Windows (and this issue is Windows specific) the maximum icon size allowed is 256x256 pixels.
> That is the size we will request and store in the MultiResolutionImageIcon.

I guess for the most system icons the size 256 is a maximum size, does it mean we
always will use it? Even if the requested size is 16x16? I guess that on the HiDPI
screen if the requested size is 16x16 we should use the resolution of size 32x32, not 256x256.
Probably the text should be rephrased.

>>  - Another question is about multi-screen environment, if the JFileChooser will be shown
>>    on the non-HiDPI screen and then moved to the HiDPI screen which icons we will request
>>    from the native and which actual icons(resolution) will we draw on each screen?(both types
>>    of icons large/small are interesting).
> Right now Swing is handling scaling and with my limited testing capability (i don't have access to
> the different multi-monitor configurations for obvious reasons) i don't see any problem. Both
> small and large sized icons got scaled together with the scaling factor change, obviously
> quality of icons with size 32 and up is much better since they all are downscale of the 256x256
> icon and both 16x16 and 24x24 icons are pretty pixelated with scaling factor 200% and up,
> but that was a trade off for allowing of the custom small icons to be used where available.

The similar(but not exactly the same) scenario is changing DPI on the fly while the JFileChooser
is visible on the screen. In that case the JFileChooser should be redrawn and correct resolution
variant should be used. For example if the file has the icons of size 32x32 and 64x64, but
does not contain the icon 48x48:

  - Scale factor is 1.0: JFileChooser requests the "large" icon of size 32x32, when this icon is
                       painted on the JFileChooser the 32x32 resolution should be used.

  - Scale factor is 2.0: JFileChooser requests the "large" icon of size 32x32, when this icon is
                       painted on the JFileChooser the 64x64 resolution should be used.

  - Scale factor is 1.5: JFileChooser requests the "large" icon of size 32x32, when this icon is
                       painted on the JFileChooser we(or the native code) should upscale the 32x32
                       resolution or downscale 64x64 icon to the size 48x48.

  - The Scale factor dynamically changed from 1to2/2to1: JFileChooser requests the "large" icon
                       of size 32x32, when this icon is painted on the JFileChooser the 32x32 or 64x64
                       resolution should be used depending from the current scale.

Best regards, Sergey.

More information about the awt-dev mailing list