Hi Anton,
On my laptop both calls are always very fast even when I open a USB
drive dir with many files.
Probably it is very rare situation but Netbeans reported it several
times and people complains on delays of tens of seconds. I could not
reproduce that.
I made a guess that following MS recommendations can eliminate delays +
I added Windows libraries icons.
--Semyon
On 6/1/2015 5:41 PM, 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
