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.
Beginning of action: Workspace tab clicked or keyboard shortcut entered (first time this session) Initial Feedback: Tab appears clicked (or other feedback as appropriate -- maybe tab could change even if contents lag?) Maximum time allowed: 100 ms Completion: Workspace changes Maximum time allowed: 1000 ms All subsequent switches in the same session should complete in 100 ms.
Dafe's measurements - testing conditions: PC Dell Pentium III, 600Mhz, 512 MB memory, JDK 1.4.1, Netbeans Main trunk build, mounted sampledir local filesystem, opened 8 java source files, 3 plain text files. times in milliseconds. first time: Editing(editors opened, maximized) -> GUI Editing(default, only explorer): 766 subsequent: GUI Ed. -> Editing: 453, 531, 422 first time: Editing(editors opened, maximized) -> Debugging(default, only explorer): 4250 subsequent: Editing -> Debugging: 266, 235, 219
According to our first evaluation, there are two parts: (1) The window system part of the problem lies in the number of opened TopComponents (and modes) in the workspace. This should be proved by measured numbers, then analyzed and solved. (2) Otherwise, the poor responsiveness is caused by the content initialization (i.e. form editor, debugger) when used for the first time - so modules issue.
As for (1), my measuring shows 200 more ms (in switching GUI -> Editing time) for ~40 files opened in editor. Occasionally, there are longer delays (even 600 ms) when browsing in files between switches (then also the time to leave Editing WS is longer), but don't know what could cause this.
Marian's measurement (time in milliseconds): conditions: - SUN UltraSparc60 / 512 MB RAM / Solaris 5.8 / CDE - JDK1.4.1(01) - [nb_dev](200211140100) , MDI - mounted sampledir switch workspaces (by click on "workspace tab"): Editing -> Debugging 2899 241 297 Editing -> GUI Editing 313 165 211 Editing -> GUI Editing (opened ColorPicker) 15040 973 881 Test cases described on page : http://performance.netbeans.org/qa/TestSuites.html#switch_workspaces
passing to winsys owners.
I propose to make an offer for user responsiveness by pieces. Dafe's proposition about change concrete workspace's TAB after click like Initial Feedback is good start. Then empty windows could appear (e.g. case of switching into Debugger Workspace with Debugger Window). And then content of windows could be filled in. During all process of switching I recommend to use Wait cursor like key feedback about switching.
I try to summarize: - always switch the ws tab immediately (initial feedback), - use wait cursor until switching is done. Specifically for *the first use* of the workspace (which takes long time to initialize), an empty workspace area could appear immediately with a text like "Initializing Debugging workspace..." in the center, accompanied with the wait cursor - until the workspace is loaded and displayed. If in SDI, the text would appear in status line, no windows would be visible during initializing. I think the empty workspace should not appear for second/subsequent switch (neither the wait cursor probably) as these switches are quick. Comments?
I sow last version created by Marek Slama and it looks fine. Difference between first and subsequent switching is ok as well. I agree with Tomas's suggestion and text "Initializing name_of_workspace workspace..." should be displayed only for first switching. It should be situated at the Status line for SDI and for MDI in center of Desktop area. There is problem with displaying wait cursor currently, but Marek is able to fix it. Then it will visible during all switching process.
Looks fine in current build (20030203). Maybe the text would be better readable if in some other color than black. Also, the text remains for a while even after the windows appear, it is moved as the desktop shrinks. That's not nice.
Method JDesktopPane.paint() is overwritten (this is center area). WindowManagerImpl has flag. Flag is set to true during workspace switching. I think problem is when JDesktopPane.paint() is called to refresh itself after switching is finished.
Fixed.
I sow last version and I would to ask about text in the blue desktop. Is it possible to hide it when Desktop area is resized yet? It means in that time when other windows (Explorer, Properties, Output) are already appeared during switching.
I can try. When does it happen and what build do you use?
I checked it on build 20030207-0620. Best solution is to show "Initializing name_of_workspace workspace..." text only until first drawing into the Desktop area. Then it has to be hidden and all windows should appear all at once. Then all "slow windows" (Source editor, Form editor) could be filled by their content subsequently.
issue doesn't apply to new window system - verified