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.

Reply via email to