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.

Bug 29828 - provide API for listening to node children creation start and finish
Summary: provide API for listening to node children creation start and finish
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: t_h
URL:
Keywords: API, PERFORMANCE, UI
Depends on:
Blocks: 27777 35833 49675
  Show dependency tree
 
Reported: 2003-01-07 12:07 UTC by David Simonek
Modified: 2008-12-23 10:39 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Test for the node expansion performance (5.37 KB, patch)
2003-01-13 14:27 UTC, Petr Hrebejk
Details | Diff
expanding app node with one module: log with timestamps & call stacks (20.13 KB, text/plain)
2003-01-15 01:20 UTC, Jeri Lockhart
Details
expanding app node with 6 modules: log with timestamps & call stacks (76.63 KB, text/plain)
2003-01-15 01:21 UTC, Jeri Lockhart
Details

Note You need to log in before you can comment on or make changes to this bug.
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)