Alexey, Sergey,
here's the latest version of the fix:
http://cr.openjdk.java.net/~kizune/8182043/webrev.02/
It adds one more native method - hiResIconAvailable
that queries if system will be able to provide high resolution icons for
a given file.
Now i have tested three approaches with the FileManager:
The old one - at magnification 150% can be seen here:
http://cr.openjdk.java.net/~kizune/8182043/example/fchooser_old_150.PNG
I changed the behavior by making the icon loaded by the FileChooser a
MultiResolutionIcon
carrying both small and large icons at the same time.
The result looks much better - here's the same view with the
intermediate fix:
http://cr.openjdk.java.net/~kizune/8182043/example/fchooser_inter_150.PNG
But then i added the new native method and in FileChooser i'm getting
the multiResolutionIcon
for all the files for which it is possible. The result looks much crisper:
http://cr.openjdk.java.net/~kizune/8182043/example/fchooser_new_150.PNG
But there's one catch: new way of retrieving icons does not get the
custom drive
icon (can be seen at disk C: - the windows logo identifying the windows
system drive
is no longer present). I am questioning myself, what is better: to have
better icon quality
and missing custom disk logo or to have custom disk logo and mediocre
icon quality?
/Alex
On 22-Jun-20 11:27, Alexander Zuev wrote:
Hi Alexey,
sorry for late responce, after fixing that initial error with the wrong
icon sizes pulled i found a lot of corner cases that needed some
additional digging.
On 18-Jun-20 20:56, Alexey Ivanov wrote:
On 18/06/2020 02:30, Sergey Bylokhov wrote:
On 6/17/20 5:50 pm, Sergey Bylokhov wrote:
I guess it is too early to compare behavior before and after the
fix since the fix has a few bugs.
- It does not fetch several sizes, as it was expected from the
code, but load only one native size
and map it to the different resolutions.
Yes, I re-read your message and found this mistake.
I fixed it locally.
Then I noticed JFileChooser does not really use the new method which
returns MRI, so this explains why JFileChooser never adjusts the
icons according the screen DPI.
I modified Win32ShellFolder2.getIcon(boolean) to use getIcon(size)
instead of getIcon(getAbsolutePath(), getLargeIcon), and now the file
icons are updated when JFileChooser window is moved from standard DPI
monitor to a High DPI one (150%) and back. I noticed one artefact
though: the customised icons from disk drives disappeared, some file
icons look clipped, on either monitor.
I also noticed this behavior, some icons retrieved with the
extractIcon method got clipped or improperly scaled.
I tried to dig deeper and found that it happens when
pIcon->GetIconLocation function returns "*"
as location of the resource file. I haven't found exact reason for
that but when this is the case then
getIconBits function always retrieves 32x32 icon no matter what icon
size we requested.
We then scale it down to 16x16 and the result is unpleasant.
I'm trying to find another way of retrieving the custom icon but for
now i would say that
for the small icons the approach of getIcon function which uses
SHGetFileInfo holds better results.
So far the approach that seems to be working is to check if we have a
high resolution
icon available by requesting icon location. If icon location is not
known we can get both
low and high resolution icons from SHGetFileInfo and store them in the
MRI. If high res icon available
then fetch all the standard resolution icons and also return them as MRI.
/Alex
