Hi Sergey,
On 24/10/2017 00:22, Sergey Bylokhov wrote:
On 17/10/2017 09:42, Alexey Ivanov wrote:
This is my understanding, before those fix the maximum size was 32x32.
It is my understanding too. Thus limiting the size of icon to 128
pixels seemed reasonable.
At this moment the buffer for icon pixels is allocated on the stack,
therefore the size cannot be dynamic. If memory for icon pixels is
allocated dynamically, the limitation can be removed.
It makes sense to address this limitation under a separate issue, do
you agree?
I agree that this can be moved to a separate bug. But my complaints
were not related to it.
- The new flags are not strictly specified. It is unclear what are
small and large icons. For example the old "getSystemIcon" specified
that it returns "an icon as it would be displayed by a native file
chooser". How the new flags are related to this? I see that the SMALL
flag is the same as the old method, and the large cion is just a HiDPI
version of default icon.
- SMALL/LARGE flags depends from the native main screen scale,
probably it is possible to remove this dependency? Otherwise in the
two screen configuration it will produce different images depending
from the main screen.
Per my understanding, SMALL and LARGE flags correspond to the previous
private API behaviour where you could get two icon sizes: 16×16 and
32×32. These flags will return the same logical-sized icons, subject to
HiDPI scaling performed by native system.
So these constants provide backward compatibility to
sun.awt.shell.ShellFolder.getShellFolder(file).getIcon(getLargeIcon):
either SMALL or LARGE.
- In case of multi-monitor config in the discussion above there was a
suggestion that the user can create MRI on top of the new API. I am
not sure how it will work because we already return MRI for most of
the files.
I am still thinking that we should investigate the possibility to
return MRI directly w/o ImageIcon/Icon wrappers. This MRI could load
data lazily depends from the destination scale. The user ill able to
get any resolution variants via getResolutionVariant(double,double)
and also can get the list of the icons attached to some file via
getResolutionVariants();
My suggestion was to create MRI internally inside the new API. [1] This
seems like the best option. On the other hand, we need to overcome
native system scaling, otherwise the rendering could be broken.
Testing performed by you [2] and me [3] shows that native system scales
the returned hIcon, and, if there are several displays in the system
with different scaling factors, the underlying icon size could be wrong.
It seems there's no easy-to-use API for icons, Microsoft admits [4]
working with icons is one of the areas where Win32 API does not provide
a DPI context. It is still possible to use low-level resource APIs to
enumerate all the provided sizes in RT_GROUP_ICON resource.
Regards,
Alexey
[1]
http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013147.html
[2] http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html
[3] http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013181.html
[4]
https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Common_Pitfalls__Win32__
