<Swing Dev> <AWT Dev> [10] Review request for 8182043: Access to Windows Large Icons

[Phil Race]

This thread is very long and despite trying I am sure I have not 
absorbed every discussion point to date.

I think a concise summary of the current opinions from Semyon would help as
I don't yet see a concensus emerging and if we are adding a new public 
API we need to be sure that
1) It is supportable ?
  - The question around whether Windows sometimes gives us a scaled 
image even when we think it
     is giving us a full resolution image is one that needs to be considered

2) returning something backed by a multi-res image seems like it should 
be explored for feasibility.
     I am not sure why a developer would need multiple images to be 
manually managed and selected
    in this case when elsewhere we can select an appropriate one 
automatically. PERHAPS we can
    even retro-fit the implementation of the existing API to support this ?

3) It does what the developer actually needs ?
     Although he is just one person, has anyone gone to ask the person 
who submitted
    this request what he would LIKE to see .. as distinct from what he 
has been doing as
    a workaround to date. By this I mean maybe he has had to manually 
select a large icon and use it
    where he needs it .. perhaps he is doing this only because we aren't 
doing it automatically ?

So I am not even really looking at the code here .. although I have .. 
we need to get the high level
issues sorted out first.

So Semyon: AI: provide that summary .. and along with it answer as much 
of 1 - 3 as you can and
also go find the submitter and ask him for input.

-phil.


On 10/24/2017 09:10 AM, Alexey Ivanov wrote:
> 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__
>