Hi Alexander, Sergey,
Sorry for my belated reply.
On 08/04/2020 21:32, Sergey Bylokhov wrote:
On 4/6/20 10:21 am, Alexander Zuev wrote:
Hi Alexey,
i moved method from the new class to the FileSystemView and it
works, however when
i tried to use it in the JFileManager on Windows i found that
JFileChooser only uses large
icons in Places tab and with my code icons there are significantly
worse even on 200%
magnification. They are sharper but the way we scaling them down just
makes them a
pixelated garbage. You can look at the compare yourself:
The old method "FileSystemView.getSystemIcon(File)" as well as
ShellFolder.getIcon(boolean) also
uses MRI, and works fine. As far as I understand we should be able to
replace the usage of
ShellFolder.getIcon(true) by the new method
FileSystemView.getSystemIcon(File, 32x32). Also we
should be able to re-implement FileSystemView.getSystemIcon(File) by
the FileSystemView.getSystemIcon(File, 16x16).
And this should not cause any visual regressions, otherwise, we have
some issues in the new method.
I agree.
The new API provides access to larger set of icon sizes rather 16×16 and
32×32 only. But I'd expect the same image from new API that was provided
via the old API.
http://cr.openjdk.java.net/~kizune/8182043/compare/
Naming is obvious - *old* are the original rendering, *new* is the
modified with multiresolution image,
number at the end - magnification percent. Yes, the old icons look
pretty blurry, but are new ones look any better?
Unless we change the way we downscale images in icons any images with
high details will turn into this i'm afraid.
It is not necessary to downscale the image which we fetch from the
native, I guess the reason
is that we request the size 256x256 from the native and then downscale?
This is exactly the reason.
JFileChooser requests the 32×32 icon, we get the 256×256 icon and
downscale it to 32×32. The result of downscaling cannot be as crisp as
manually tuned icon for 32×32.
Can't we always get the requested size from the native?
This will get the best possible image from the icon resource when the
requested size is available in the icon. If not available, the native
will scale the icon to the requested size.
So i'm proposing making the new method available for user to request
image of arbitrary size but i don't think using it in
JFileChooser is a good idea.
Your own test shows the quality of the icon is poor; the new API cannot
replace existing one. Why would a user want it then? I propose to pass
the requested size to extractIcon() unconditionally.
Unless, of course, we create the true multi-resolution image with all
the resolution variants
rendered by the system - but that is impossible at the moment (as
Eiric pointed out before) due to the JDK-8212226
not fixed yet - we will have errors on resolution switch or on moving
of the window between screens with different
magnification factors.
Then how the old getSystemIcon(File) and ShellFolder.getIcon(boolean)
work?
I don't quite understand the mechanism but the icons returned change
with DPI. This means in HiDPI environment, we get the correctly sized
icon to the current DPI.
The ultimate goal of this API could be to provide an MRI which stores
all the available icon sizes and loads dynamically the size that's most
appropriate to the current display settings. Raymond Chen has a blog
post about the format of the icon resources [1]. If we do that, we will
handle all the scaling ourselves and will be able to define our own
algorithm for choosing the closest match. As explained in
LookupIconIdFromDirectoryEx [2], LoadIcon and LoadImage “use this
function to search the specified resource data for the icon… that best
fits the current display device.”
/Alex
<SNIP>
[1] https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083
[2]
https://docs.microsoft.com/en-ie/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex
--
Regards,
Alexey
