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.
I suspect a new one is being created every time, or at least its graphics context. Cache or make it lightweight? 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 find dialog invocation from Source Editor 1137 238 152 http://performance.netbeans.org/qa/TestSuites.html#find_dialog_SE
It seems that we have still problem with 1st invocation at least on some platforms. It can be some L&F issue on WinXP but I do not know why JDS is so different than RedHat9. current numbers for 1st and next invocations: W2k: 300-500ms, ~200 RH9: ~500ms, 200-250ms JDS2: ~1000ms, 300-450ms Solaris: 2-2.3s, ~250ms WXP: 900-1200ms, <200ms
So what is the goal here? 1000ms first and 100ms for subsequent inovactions or just no regressions? Against which numbers? (the issue is against 3.6) Assigning to future preliminarily.
We have a problem with 1st invocation on WinXP and Solaris. Perhaps recent changes tah Marian Petras did helped here.
Changing subcomponent to search.
Please, reevaluate. A few users in performance survey complained about slow reaction of CTRL+F action: * When I want to search, I often do CTRL+F and start typing what I'm looking for and often, since the popup have not appeared, the characters go to the edited file... It's really annoying. * Find window should appear faster after Ctrl+F
I agree that there's an issue with first invocation of the find dialog. Consequent invocations are fast, but the first one takes a while. Observed on JDS.
Can we fix this in 4.1? Dusan recently did some fix of a dialog where he remembered the pressed keys until the dialog was opened. If we cannot improve the startup speed we should IMO do something like this as it is annoying when the text user types gets into editor instead of dialog. This can really be an issue for users with slow machines. Thanks.
Current state: - after Ctrl+F typed characters are captured and inserted into (later appearing) find dialog. - swing panel that holds the components of the find dialog is cached between invocations. Dialog instance is not cached as it would cause problems (already tried earlier). Not sure what more could we do except pre-initialization of the find dialog's panel content at some point (probably warmup task). I assume this is not desired. Setting TM to "future" and removing fix-in-41. If anyone has any idea for improvement please speak up.
I agree, as long as users are not able to type text which should go to find dialog into IDE instead it's fine. I was able to reproduce it around 14 days ago but it works well today, all text goes to find dialog.
To Mila: what is wrong with caching dialog instance? I ask because we had a discussion with Dafe recently whether dialogs created by DialogDisplayer should be disposed on close or not. What you need is to override this and do not dispose on close to get some benefit from caching and then it should work OK (maybe threading can break it again). Or is it some unrelated problem? I do not insist on caching, I am just curious.
I remember that there was an issue with a grey dead editor pane frame appeared once you invoked find dialog. It used to be when the SDI windowing mode was the only one which is no longer true although some users still use it. It was because: 1) File1 was opened in editor. 2) Ctrl+F => Find dialog created and parented to editor frame of File1. That was necessary because parenting to Main window returned focus back to Main window after closing of the Find dialog which was unacceptable. 3) File1 closed (editor frame was disposed but it was still parented by the cached find dialog). 4) File2 opened (new editor frame created). 5) Ctrl+F caused to open the cached find dialog but with the zombie gray File1 editor frame behind it. Not sure whether this still applies with the current JDKs etc. so we could possibly try again e.g. test to pass null as JDialog's owner etc.
Aha. I understand. OTOH it seems to me that we should always set parent in SDI when the dialog is displayed or probably better is to null the reference when it is closed so the editor is not retained needlessly. Of course we can ask winsys maintainers if this problem persists.
It's not entirely clear to me what's the exact difference between "owner" and "parent" regarding the dialogs. If you look at how owner is handled there is e.g. no setOwner() in JDialog. The getOwner() returns parent. The Window's constructor with owner parameter first gets the owner's graphics configuration and then calls ownedInit(): private void ownedInit(Window owner) { if (owner == null) { throw new IllegalArgumentException("null owner window"); } this.parent = owner; this.weakThis = new WeakReference(this); owner.addOwnedWindow(weakThis); } We could call setParent(null) but then the getOwnedWindows() in the owner will return this dialog until GCed which is probably harmless. We can restore parent's reference upon displaying of the dialog and if the parent dies we can possibly recreate the find dialog to get to a clean state.
update NB Dev (200607311800) Lin(1.5.0_07) Lin(1.6.0) Sol9 Sol10 WinXP(1.5.0_07) Win XP(1.6.0) Find in Source Editor dialog open [ ms ] / 1000 ms 1st usage 564 939 580 515 651 706 Subsequent usage 122 139 232 166 85 191
No 'Find' dialog anymore. We will be using the search bar from now on. IMO it should be faster, because the component is created when the editor is created. Later on the actions only show/hide it without any difference between the first and subsequent invocations.
build 200708270000 verified