Created attachment 56489 [details]
stack trace in console

there's nothing really suspicious in the stacktraces. Only the job that is supposed to be happening, is performed. It
seems to be instant on my mac. Did you have any other IO intensive tasks on the computer running at the same time? like
hg update etc..

reassigning to apisupport for evaluation. (it could be related to the fact we have 600+ projects in one folder, but I'm
not sure it matters). The issue is most likely IO bound and not much can be done here. One cannot pre-load the contents
of the folder or anything like that..

Nothing to be done here when using the current ProjectChooserAccessory. In order to display the project badging on
icons, you need to do disk stats. There is no trivial way to ask JFileChooser to _update_ an icon after it has first
been displayed, so the icon needs to be calculated synchronously in EQ.

And if your disk caches are cold, some inodes need to be read in before that can happen. If there are hundreds of
project dirs, that can take a moment.

I will attach a demo showing that at least in Metal L&F it is possible to update icons asynchronously using the trick of
calling setFileView. Maybe this could be used in PCA to badge project nodes asynchronously. You could even do one
relatively fast but asynch pass calling isProject and retaining this info, adding a simple project badge; and then for
every folder for which getIcon is called (i.e. which has been displayed in the scroll viewport?), do a slower second
pass calling loadProject and displaying the actual project icon.

Created attachment 56637 [details]
Demo of incrementally updating icons in a JFileChooser

*** Issue 133640 has been marked as a duplicate of this issue. ***

See issue #109206 for project-type-specific badging.

It can be fixed pretty easily, giving dramatically better performance for the Open Project dialog, by doing this in
DirectoryChooserUI.java:

        tree = new JTree(new Object[0]) {
            protected void processMouseEvent(MouseEvent e) {...as before...}
            public void setRowHeight(int rowHeight) {
                if (rowHeight > 0) {
                    super.setRowHeight(rowHeight);
                }
            }
            public boolean isLargeModel() {
                return true;
            }
        };

Then the OP dialog only asks isProject for subdirs which are actually displayed, causing far fewer disk accesses.

Unfortunately this then seems to regress issue #106223, easily reproduced by running with --fontsize 18 in Ocean L&F. I
am not sure how to set a fixed cell height appropriately for a tree. For lists, you can set a prototype value, but there
seems to be no similar call for JTree.

I am experiencing this problem with NB 6.1.  I did a fresh install and started opening projects.  After I had about 5-8
projects open, the open project dialog would become frozen.  Every time I click inside the window it would beep at me. 
I found that I could use tab/shift-tab/arrow keys/enter to navigate around, select a project and open it.

With the help of a trick from Tim (first Google hit for "jtree fixed row height"!) I think I have it working - should
now calculate isProject only for visible folders, while using the correct row height for the desired font size. Seems OK
at least on:

- Ubuntu
-- JDK 5: Metal regular, --fontsize 18
-- JDK 6: Metal regular, --fontsize 18, GTK, GTK with Gnome font size 18
- XP
-- JDK 6: Win32 regular, --fontsize 18 (setting Windows Desktop prefs to use "Extra Large" fonts had no apparent effect
on most text in the IDE)

Tim please review:

http://hg.netbeans.org/core-main/rev/190d195fb7bc

Integrated into 'main-golden', available in NB_Trunk_Production #243 build
Changeset: http://hg.netbeans.org/main/rev/190d195fb7bc
User: Jesse Glick <jglick@netbeans.org>
Log: #127170: improved performance for Open Project by only inspecting dirs which are currently visible.

Looks right.  Super-micro-nits, feel free to ignore:
 - Could probably call setLargeModel(tree) instead of overriding isLargeModel() and save a few bytes
 - Slightly more efficient might be g.getFontMetrics(getFont()).getHeight() and skip setting the font on the Graphics object
 - In later iterations of code like this, I moved the resetting of firstPaint to updateUI().  Only could make a difference if icon size changed and you were 
actually using default icons looking up their size and storing that instead hard coding a default height.  Someday might matter for vector based icons and 
high-res displays, but supporting that will require other changes anyway, and updateUI() is going to call setFont() anyway.

BTW, if you want to support "Jesse Mode" for the file chooser (force a short height for all cells), you'll want to look up 
System.getProperty("nb.cellrenderer.fixedheight") (I think that's the string) and use that instead of the font height if present.

Anyway, this will probably help a lot with the performance issue.

I override isLargeModel() because I think I saw some JRE code calling setLargeModel(false) under certain conditions and
I wanted to make sure this would not happen.

Regarding other points, you clearly know more about the subject than I do - if you see something you think needs to be
fixed, feel free to fix it (or add a comment to the source suggesting that it could be changed in a certain way if
certain problems arise in the future).

Also fixing for quickfilechooser: contrib #2efa20b0b23c