Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 109703 - Netbeans 6.0 M10 FileChooser is too slow
Netbeans 6.0 M10 FileChooser is too slow
Status: CLOSED FIXED
Product: platform
Classification: Unclassified
Component: Window System
6.x
PC Windows XP
: P2 (vote)
: 6.x
Assigned To: David Simonek
issues@platform
jdk_bug_6578753
: JDK_SPECIFIC, PERFORMANCE
: 104255 106420 110525 110625 113203 113581 113587 113808 115792 116805 116812 118861 119711 119774 120078 120287 121631 121648 121762 123180 126329 154189 157904 181170 (view as bug list)
Depends on:
Blocks: 120663 124520 124831 176864
  Show dependency treegraph
 
Reported: 2007-07-14 00:01 UTC by jrenatogonzalez
Modified: 2011-06-09 09:56 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jrenatogonzalez 2007-07-14 00:01:06 UTC
In every "Browse..." button or every time a JFileChooser that NetBeans open, it takes too much time to open, and then 
for every folder selected takes too much time to refresh view.
Comment 1 Karthikeyan Rajeswaran 2007-07-16 18:16:08 UTC
See also:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6317789
"..the bug is not present if you set the "useShellFolder" property to false..."
Perhaps NetBeans can provide a way for the user to set this property, which may be useful for those users who find the
UI too slow.

Also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372808
Comment 2 Karthikeyan Rajeswaran 2007-07-16 19:42:32 UTC
This issue was originally reported on the nbusers forum at:
http://www.netbeans.org/servlets/BrowseList?list=nbusers&by=thread&from=799682

The forum thread was updated as follows:
   After removing 3 zip files on my desktop, the performance issue with JFileChooser is gone!
   It seems to be a issue on jre and not on netbeans….

It looks like the problem seems to be with accessing folders on the Windows desktop itself (in fact the chooser is known
to hang when a shortcut to desktop is on the desktop, leading possibly to infinite loop..)

Perhaps NetBeans can consider working around this problem by exlcuding windows desktop itself...not sure if that is
advisable or feasible...
Comment 3 David Simonek 2007-07-17 12:34:28 UTC
Lowering to P2, please don't abuse priority or it will not work at all...

However providing command line switch to disable shellFolder seems reasonable, as this report is repeated, users find
this slowness to be a problem...
Comment 4 Antonin Nebuzelsky 2007-07-18 10:03:53 UTC
> this report is repeated

yes, see also
http://www.javalobby.org/java/forums/t98389.html?start=0#92159232

Dafe, try to implement what you suggested yesterday when we discussed this. Measure the time it takes to initialize
shellFolder and if it is too long, show the user a hint that she may have many/large files on Desktop.
Comment 5 _ tboudreau 2007-07-18 17:14:18 UTC
FWIW, there is a cheap trick to make file choosers open very fast, which I use in standalone applications.  It only works if you cache and reuse one 
JFileChooser, and you are really moving the work to startup, but it does work:

static JFileChooser chooser = new JFileChooser();
static {
    CellRendererPane pane = new CellRendererPane();
    pane.add (chooser);
    chooser.doLayout();
}

Probably for a lot of cases we could just reuse a single filechooser.   Maybe something to add to the Dialogs API?
Comment 6 Marian Mirilovic 2007-07-23 07:37:52 UTC
*** Issue 110525 has been marked as a duplicate of this issue. ***
Comment 7 Marian Petras 2007-07-23 17:55:22 UTC
*** Issue 110625 has been marked as a duplicate of this issue. ***
Comment 8 Marian Petras 2007-08-21 09:15:42 UTC
*** Issue 113203 has been marked as a duplicate of this issue. ***
Comment 9 David Simonek 2007-08-23 20:42:20 UTC
*** Issue 113587 has been marked as a duplicate of this issue. ***
Comment 10 Antonin Nebuzelsky 2007-08-28 13:03:19 UTC
*** Issue 113581 has been marked as a duplicate of this issue. ***
Comment 11 David Simonek 2007-09-26 14:25:19 UTC
*** Issue 116805 has been marked as a duplicate of this issue. ***
Comment 12 Jana Maleckova 2007-09-27 10:40:32 UTC
*** Issue 116812 has been marked as a duplicate of this issue. ***
Comment 13 David Simonek 2007-10-02 14:58:40 UTC
Integrated bug workaround, based on Tim's suggestion. It solves problem of first slow start of JFileChooser (see JDK bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516), but I think there will still be problems of slow browsing,
mentioned in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578753 and related. Sadly nothing we can do with it.

/cvs/core/swing/dirchooser/manifest.mf,v  <--  manifest.mf
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/resources/layer.xml,v
done
Checking in src/org/netbeans/swing/dirchooser/resources/layer.xml;
/cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/resources/layer.xml,v  <--  layer.xml
initial revision: 1.1
done
RCS file: /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java,v
done
Checking in src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java;
/cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java,v  <--  JFileChooserWarmUpTask.java
initial revision: 1.1
Comment 14 Petr Nejedly 2007-10-12 14:09:42 UTC
*** Issue 104255 has been marked as a duplicate of this issue. ***
Comment 15 Antonin Nebuzelsky 2007-10-17 12:22:48 UTC
*** Issue 106420 has been marked as a duplicate of this issue. ***
Comment 16 Marian Mirilovic 2007-10-23 13:50:33 UTC
*** Issue 119711 has been marked as a duplicate of this issue. ***
Comment 17 Antonin Nebuzelsky 2007-10-24 12:59:52 UTC
Reopening. The fix does not work for me.

With Beta 2 I have two twenty meg zip files on desktop of my Win XP machine and opening the Open Project directory
chooser takes 1:35 min. Before invoking the action I left the IDE running for five minutes, so the warmup workaround
should have finished, but it obviously did not work.

Now I tried patching DelegatingChooserUI with
  fc.putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);
as suggested in the JDK bug and this really helped.

I believe the only safe way for 6.0 is now patching it this way. The users will miss the quick navigation sidebar, but I
do not know about a better fix.

The issues against JDK were escalated and they should be fixed for 6u4, so we can reconsider the navigation sidebar for
next NetBeans release after we verify the problem is fixed with 6u4.

For reference:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372808
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578753
Comment 18 David Simonek 2007-10-24 13:42:49 UTC
I tried really hard and spent some time on this and workaround worked well for me...

Anyway, I've given up:

Removing src/org/netbeans/swing/dirchooser/resources/layer.xml;
/cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/resources/layer.xml,v  <--  layer.xml
new revision: delete; previous revision: 1.1
done
Checking in src/org/netbeans/swing/dirchooser/DelegatingChooserUI.java;
/cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/DelegatingChooserUI.java,v  <--  DelegatingChooserUI.java
new revision: 1.4; previous revision: 1.3
done
Removing src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java;
/cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java,v  <--  JFileChooserWarmUpTask.java
new revision: delete; previous revision: 1.1
done
Checking in manifest.mf;
/cvs/core/swing/dirchooser/manifest.mf,v  <--  manifest.mf
new revision: 1.4; previous revision: 1.3
Comment 19 Antonin Nebuzelsky 2007-10-24 16:16:06 UTC
*** Issue 119774 has been marked as a duplicate of this issue. ***
Comment 20 David Simonek 2007-10-26 11:35:31 UTC
*** Issue 120078 has been marked as a duplicate of this issue. ***
Comment 21 Antonin Nebuzelsky 2007-10-29 22:23:28 UTC
*** Issue 106420 has been marked as a duplicate of this issue. ***
Comment 22 David Konecny 2007-10-30 07:38:23 UTC
*** Issue 120287 has been marked as a duplicate of this issue. ***
Comment 23 Antonin Nebuzelsky 2007-10-31 16:44:41 UTC
*** Issue 113808 has been marked as a duplicate of this issue. ***
Comment 24 Marian Mirilovic 2007-11-01 17:56:16 UTC
*** Issue 115792 has been marked as a duplicate of this issue. ***
Comment 25 David Simonek 2007-11-12 11:05:34 UTC
*** Issue 121648 has been marked as a duplicate of this issue. ***
Comment 26 ehucka 2007-11-14 09:53:23 UTC
*** Issue 121631 has been marked as a duplicate of this issue. ***
Comment 27 Jana Maleckova 2007-11-15 09:20:57 UTC
*** Issue 121762 has been marked as a duplicate of this issue. ***
Comment 28 Peter Pis 2007-12-04 09:40:20 UTC
*** Issue 123180 has been marked as a duplicate of this issue. ***
Comment 29 Karthikeyan Rajeswaran 2007-12-05 01:57:16 UTC
> ------- Additional comments from anebuzelsky Wed Oct 24 11:59:52 +0000 2007 -------
> The issues against JDK were escalated and they should be fixed for 6u4, so we can reconsider the navigation sidebar for
> next NetBeans release after we verify the problem is fixed with 6u4.

Should this bug be reopened for 6.1 so that this issue is tracked correctly for the next version?
Comment 30 Antonin Nebuzelsky 2007-12-05 12:33:06 UTC
> Should this bug be reopened for 6.1?

No. A separate issue should be filed, an enhancement to reenable the quick navigation sidebar after the JDK bug is fixed
in an update of JDK6.

BTW, at this moment we know the bug is fixed in 6u10, and not fixed in 6u4.
Comment 31 Peter Pis 2008-02-26 09:41:45 UTC
*** Issue 126329 has been marked as a duplicate of this issue. ***
Comment 32 Petr Chytil 2008-04-23 09:32:10 UTC
*** Issue 118861 has been marked as a duplicate of this issue. ***
Comment 33 Peter Pis 2008-08-25 08:39:44 UTC
*** Issue 144898 has been marked as a duplicate of this issue. ***
Comment 34 Lukas Hasik 2008-12-02 09:55:16 UTC
*** Issue 154189 has been marked as a duplicate of this issue. ***
Comment 35 Stanislav Aubrecht 2009-02-04 12:31:53 UTC
*** Issue 157904 has been marked as a duplicate of this issue. ***
Comment 36 rbncha 2009-11-18 09:42:45 UTC
I use NetBeans PHP 6.7 version. Have been testing (and using when *possible) since it was 5.5. File browser performance is very poor since then. I don't understand why you guys are not interested to resolve this annoying issue.

I'm not sure, but seems the file browser also walks into least directory of each current directory (when I click on the + sign or double click the folder). Also, if I try to open 4/5 files at a time by (ctrl + click on files) it is noticeably much slow.

(*because it's really quite slow than other IDE's)

Keep up the good work. Good Luck !
Comment 37 Jaroslav Tulach 2009-11-18 13:26:28 UTC
Please self profile your IDE as described at
http://wiki.netbeans.org/FitnessViaPartnership
and provide us more information about the slowness you are observing. Thanks.
Comment 38 David Simonek 2010-03-23 16:13:28 UTC
*** Bug 181170 has been marked as a duplicate of this bug. ***
Comment 39 Marian Mirilovic 2011-06-09 09:56:24 UTC
v/c


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo