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

[Anton V. Tarasov]

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