This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
While creating UI components for the platform, selecting the new Window Component is slow and provides no feedback. The IDE appears to lock up. Steps followed: 1. starting with a RCP module right click 2. Select New -> Window Component 3. Wait for unspecified amount of time wondering what is going on. Doing this multiple times does not speed up the process.
Created attachment 93326 [details] Profiler snapshop
Reassigning. Profiler snapshot was taken manually.
I did some investigating, it seems that the org.netbeans.modules.apisupport.project.ui.wizard.winsys.BasicSettingsPanel.setupCombo method is the main slow point in this process. On my dual core laptop it takes 5.7 seconds on initial setup. Probably the easiest way to fix this is to use SwingWorker (or the NetBeans equivalent for Java 5) to thread the process.
I put together a patch that use AsyncGUIJob but am not happy with the results. The panel now appears quickly, but the combo box still takes a while to load - which is expected - and the UI gives no indication that the user needs to wait. Is there an example of this in the current code base? I have look (briefly) at the 'New File' wizard, is there a simpler example?
Usually Utilities.waitCursor (I think) is used to indicate that the user should wait for something. I'm afraid I don't have experience with AsyncGUIJob.
I implemented logic following this example http://performance.netbeans.org/howto/wait-cursors.html currentComponent.setCursor(Utilities.createProgressCursor(currentComponent)); The formatting of the document needs fixing. I tried to use the markInvalid and markValid to get the 'next' button to only activate once the UI is ready but that did not work. I will have to investigate.
Here is my first attempt to solve this issue. Hopefully it meets the necessary requirements. This does not make the process run faster, it just improves the user experience. There are odd times when figuring out the dock modes take a long time (more than 20 seconds), this patch allows the user to cancel immediately and try the process again. The dock modes is spun off into a thread and the panel/form set as invalid (disables the 'next') once the dock modes are read, the combo box is populated and the panel is marked as valid.
Created attachment 93932 [details] Patch locking UI by threading the disk I/O to a worker thread
Thanks, applied: http://hg.netbeans.org/core-main/rev/021c53600f47 It seems to work, though I am not personally able to reproduce a pause of more than a fraction of a second so it is hard to tell.
You are lucky! This happens to me on my Work PC and my MacBook and MacPro (both snow leopard). I did find that it was less likely to happen under linux even when linux was running in vmware on my macpro. Thanks for committing.
Integrated into 'main-golden', will be available in build *201002120200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/021c53600f47 User: mvfranz@netbeans.org Log: #179548: UI blocked in Window wizard. (applied by jglick)