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.
|Summary:||provide API for listening to node children creation start and finish|
|Product:||platform||Reporter:||David Simonek <dsimonek>|
|Severity:||blocker||CC:||jeri, jglick, jskrivanek, jtulach, pnejedly, tboudreau|
|Priority:||P2||Keywords:||API, PERFORMANCE, UI|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:|
|Bug Blocks:||27777, 35833, 49675|
Test for the node expansion performance
expanding app node with one module: log with timestamps & call stacks
expanding app node with 6 modules: log with timestamps & call stacks
Description David Simonek 2003-01-07 12:07:44 UTC
Goal is to provide API which is able to inform clients: 1) when node's children are going to be obtained 2) when node's children are fully obtained and complete Original motivation is ability to provide progress mouse cursor feedback to the user during folder expand in the explorer's tree. for the original request please see issue 27777, comment from Jeri Lockhart.
Comment 1 Jesse Glick 2003-01-07 23:14:11 UTC
Rather than providing an ad-hoc API just to listen to start and finish, I suggest Tim's recommendation we taken seriously at this point: a way for a Children object to supply nodes incrementally or in ranges, much as e.g. Swing's ListModel and TreeModel do. This could provide performance benefits such as not computing off-screen nodes, in conjunction with other changes. It should encompass addNotify/removeNotify semantics, getNodes(true) and the findChild(null) idiom, listening for completion, and requests for expected child list size and for indexed subranges. Looks, Filesystems, and Datasystems might all be affected somehow. In the nearer term, Datasystems already produces folder children incrementally.
Comment 2 Jeri Lockhart 2003-01-09 23:32:03 UTC
Children.addNotify()is not called early enough for an effective cursor change. In my worse-case test, if I set the cursor in addNotify(), there's a delay of several seconds between the user expand action and the cursor change. I've put pairs of set/reset calls in four other places, in addition to addNotify(). This creates an on-off effect, instead of a steady cursor. Admittedly we have a performance problem. This request, however, is asking for a way to improve responsiveness. Even after improving performance we may still want to do a cursor change and will need an API. Another disadvantage of the piecemeal workaround described above is that I am not able to set a "Please Wait" node, but must use the cursor change. I'm bumping this up to a P2 because I feel that the workaround that I have is not entirely acceptable.
Comment 3 Petr Hrebejk 2003-01-13 14:27:12 UTC
Created attachment 8546 [details] Test for the node expansion performance
Comment 4 Petr Hrebejk 2003-01-13 14:27:53 UTC
Adding the API for wait cursor is not easy. We would have to extended the contract between nodes and views. However I'm attaching a test which (when run using internal execution) shows how long takes the expansion i.e. how much time is spent between TreeWillExpand and addNotify, between setKeys and createNodes and between create nods and TreeExpanded. It looks that the addNotify() should be OK for enabling the wait cursor. It happens almost imediately after TreeWillExpand ( 1- 10 miliseconds).
Comment 5 Jeri Lockhart 2003-01-15 01:17:47 UTC
One of the first of our methods called after treeWillExpand is com.sun.forte4j.j2ee.appasm.AsmDataObject.delayedInit() via FilterNode.getOpenedIcon(). Then methods for the J2EE modules in the application get called (com.sun.forte4j.j2ee.ejbmodule). Near the end AsmDataObject.addNotify() is called, 11.927 seconds after treeWillExpand(). I'll attach 2 logs, one for expanding an app node with one module and one for an app node with 6 modules.
Comment 6 Jeri Lockhart 2003-01-15 01:20:42 UTC
Created attachment 8569 [details] expanding app node with one module: log with timestamps & call stacks
Comment 7 Jeri Lockhart 2003-01-15 01:21:14 UTC
Created attachment 8570 [details] expanding app node with 6 modules: log with timestamps & call stacks
Comment 8 Jeri Lockhart 2003-01-28 18:12:36 UTC
After following Petr's suggestion of postponing long-running work from getOpenedIcon() until addNotify() I was able to eliminate the delay in showing the wait node (Thank you, Petr!). So now that I am able to use addNotify I don't have a particular need for this enhancement. But I'll leave it to Petr what status he wants to give it, in light of Jesse's comments of 7 Jan.
Comment 9 Jesse Glick 2003-11-17 09:56:08 UTC
Could be useful in nodes_eq_35833 branch.
Comment 10 Petr Nejedly 2004-01-09 09:44:24 UTC
Taking over the node bugs from phrebejk.
Comment 11 Antonin Nebuzelsky 2005-04-25 15:48:46 UTC
This enhancement seems to be irrelevant now. Petre, please close it if you agree.
Comment 12 Jesse Glick 2005-04-25 17:10:26 UTC
Cf. my comment from 2003, probably partially implemented by Yarda's lazy nodes work?
Comment 13 Jaroslav Tulach 2005-04-26 10:36:38 UTC
In the lazy branch, I am able to return the number of children and then return one by one when someone asks. Which is imho what you described in your comment from Jan 7 23:14:11 +0000 2003
Comment 14 Jesse Glick 2005-04-27 17:43:30 UTC
Actually in 2003 I suggested something a bit more complicated, but I believe that the impl in Yarda's lazy branch is probably adequate for our needs; there is no real need to show a wait cursor if you are not even going to try to compute off-screen nodes to begin with. There could still be circumstances, however, where the act of computing the *keys* (not just the nodes) is very time-consuming and it would be desirable to show a wait cursor until that is done. Or maybe Yarda's lazy API handles this sensibly too, I don't remember.
Comment 15 Jaroslav Tulach 2005-04-28 15:43:16 UTC
My patch diferentiates between slow&fast children. Fast are those that use the new constructor Children.Keys (int nodesPerKey). Those expand without any user indication. All the other still use the wait mouse cursor.
Comment 16 Antonin Nebuzelsky 2008-02-08 15:02:07 UTC
Reassigning to new module owner Tomas Holy.
Comment 17 Jaroslav Tulach 2008-02-11 14:21:46 UTC
The API is Children.getNodes(true)