<AWT Dev> <Awt Dev> [9] Review Request for 8022057: JFileChooser blocks EDT in Win32ShellFolder2.getIcon

[Sergey Bylokhov]

Hi, Semyon.
Same question about Library here. Does this text is used in all locales?

On 01.06.15 17:41, Anton V. Tarasov wrote:
> Hi Semyon,
>
> The idea of the fix looks ok to me.
>
> On 28.05.2015 9:44, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8022057
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8022057/webrev.00/
>>
>> The full story can be found in the jira's comments and NetBeans 
>> tracker (https://netbeans.org/bugzilla/show_bug.cgi?id=188001).
>> It seems the bug proposes to change the design of the AWT shell 
>> support on Windows platform. But instead I tried to eliminate the 
>> user experience issue it can be a good step to improve the situation.
>> The user experience issue is the JFileChooser spontaneous delays 
>> caused by getIcon(): I could not reproduce this under Win7 and 
>> jdk8/9. But I found in MSDN that ExtractIcon Win32 API call can take 
>> significant amount of time in some cases. Mostly when the file is an 
>> executable or a link and its icon is not cached yet.
>> MS propose a way how to avoid that: use asynchronous flag GIL_ASYNC 
>> with GetIconLocation call which then may return E_PENDING which means 
>> consequent ExtractIcon call can take time. There are several ways to 
>> handle E_PENDING return I propose just to use the default icon for 
>> the file which can be obtained with GIL_DEFAULTICON flag and should 
>> be much faster. Since I cannot reproduce the issue I don't know how 
>> effective it will be.
>
> But did you simply try to load with GIL_DEFAULTICON for a sanity 
> check? Is it really much faster?
>
> Regards,
> Anton.
>
>> Also in the fix I added possibility to get Windows-Libraries icons, 
>> which were not available before in the JFileChooser.
>>
>> --Semyon
>


-- 
Best regards, Sergey.