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.
This applies to both FS tab and project tab. When holding arrow key for some time, explorer speed is not enough to keep the speed with keyboard auto repeat (of course, I have fastest autorepeat set, as everybody). probably cause by property sheet refreshes
Idea mentioned recently - if the selection is changed by keyboard, could not be the notification about the selected nodes sent with a delay (so the quick changes are coalesced and not fired individually)? Currently this technique is already used, but one level above, in (some) listeners.
Created attachment 8036 [details] Patch to use large model for explorer tree
Created attachment 8037 [details] OptimizeIt output with large model
Created attachment 8038 [details] OptimizeIt output for normal model
Couple of comments: one possible way can be using fixed height for explorer tree rows and large model to optimize explorer displaying. Unfortunately results obtained with attached patch are worse than our current solution. I tried to walk through whole structure of about 40 filesystems with org.openide.explorer.view and javax.swing.tree expanded. This holds with or w/o ImageIcon caching. Tried with internally available build of JDK 1.4.2 (b08) because there are serious troubles with large model in JDK1.4.1 such JDK bug 4763206. Given this we may fix the row height as it should not hurt anything but it also doesn't speed up.
passing to explorer and its owner Jiri. Fixed height results are dissapointing, but never mind, there are other areas to explore: - try to disable selected node fires from explorer and you'll experience visual speed-up (at least on my machine). Explorer is than able to kepp the pace of keyboard autorepeat. Possible solution: coalesce selected nodes changes, because they're expensive (repaints of toolbar buttons - enable/disable).
David Strupl asked me to take care of the updating the explorer part of this this week (improve PropertySheet.DelayedUpdater). One thing: It might really be better for the explorer component to do the coalescing of events & avoid firing selected node changes. Otherwise anything else that is listening can still be a bottleneck even if property sheet is made more efficient(editor toolbar? outline panel?).
Davide, please look at problems with so fast changing ExplorerManager.setSelectedNodes(), think out a delay firing the changes. The navigation should not freeze on refresh a property sheet during navigation, it should be more fluently. Tim, pls take look at PropertySheet$DelayedUpdater if it could be rescheduled till the navigation runs.
DelayedUpdater can certainly be modified. I am just not sure it's the right place. If anything else has the same behavior as PropertySheet (updating a UI on each change of selected node), all the benefit of optimizing it in PropertySheet goes away - it will be slow again, unless that component also copies DelayedUpdater. So we end up with DelayedUpdater copied all over the place. Wouldn't it be better to do it in one place? I can even imagine two different methods for adding Node listeners, one that is immediate and one that coalesces events and waits until the changes have "calmed down" - the performance characteristics of both immediate and non-immediate are useful for different things.
Lowering to P2, not so big problem as I thought before.
I will investigate where it could be pooled the changes of selected nodes, Yarda recommends the ExplorerPanel.
Created attachment 9006 [details] current state when change of activated is fired immediately
Created attachment 9007 [details] current state when change of activated is never fired
Created attachment 9008 [details] state when changes of activated nodes are pooled
Created attachment 9011 [details] proposed patch to coalesce firing
Observation: The fluent navigation breaks the changes of the activated nodes. These changes force update of a property sheets, update of the toolbars, update action etc. (see navigte_with_activate.html, a couple of firing change "activated nodes" property takes 25% of whole time during navigation, rest is taken by JTree/Keyevents management). If I removed fire change direct in TreeView then a selection change takes only under 0.5% of time (see navigte_without_activate.html). I propose coalescing the "activated node" change in ExplorerPanel and fire the change after a given time (250 is best I think) when repeating. The support for coalesce in PropertySheet can be removed. After proposed patch, the firing and reactions take under 1% of time (see navigte_after_patch.html) thus speeding up is considerable.
fixed in maintrunk, the patch27781.diff with the minor chnages was applied User: jrechtacek Date: 03/02/19 02:42:51 Modified: src/org/openide/explorer/propertysheet PropertySheet.java Log: implementation task #27781, the repeating changes of activated nodes are coalesced, DelayUpdater is moved from PropertySheet to ExplorerPanel Revision Changes Path 1.42 +63 -1 openide/src/org/openide/explorer/ExplorerPanel.java 1.104 +8 -45 openide/src/org/openide/explorer/propertysheet/PropertySheet.java
Reopened, the applied patch leads to P1 defect 31244. The patch must be temporary reverted, a other how to fix 31244 and also keep this responsiveness improvement is developed on the branch issue_31244. The switch -J-Dnetbeans.delay.tc=true enables this functionality on current sources.
removing TEGAL milestone, this is too risky and we won't integrate this into Tegal.
Repaint of property sheet is delayed now. At least delay of repaint there, as long as GUI tests can failed with previous patch (see issue 31244). This improvement was committed in main trunk, will be merged also to release35. User: jrechtacek Date: 03/03/11 08:02:46 Modified: src/org/openide/explorer/propertysheet PropertySheet.java Log: impl issue 27781, delayed repaint property sheet on change of selected nodes
Note: implementation of "delayed repaint property sheet on change of selected" was merged in release35.
Assigned to new owner.
Isn't this rather a defect? One almost cannot use keys in the project explorer because of slowness of moving and eating up of 100% CPU.
Martin is right, it's gona be very slow and unusable ...
This is now fixed, I believe. See last comment at issue #61261.
Verified in Build 200507041800, JDK 1.6.0-ea
Sorry in build 200508041800
Yes, it's better. But selection still doesn't move but rather jumps. Every third - fifth .java node is selected as cursor is moving and still eats up 100% CPU (which is secondary problem - at least for me). Works perfectly for e.g. package nodes but is still very inconvenient to use when moving through a bunch of java classes. Which is very common, 2-4 open packages with 10-20 java classes.
Sorry, problem was with my own FileOwnerQueryImplementation which is not part of daily builds. It works nice now.
v/c