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:||EQification of Nodes and Looks|
|Product:||platform||Reporter:||Jesse Glick <jglick>|
|Severity:||blocker||CC:||jtulach, phrebejk, pnejedly, tor, ttran|
|Issue Type:||TASK||Exception Reporter:|
|Bug Depends on:||29828, 32305, 32708, 36749, 37169, 37291|
|Bug Blocks:||30702, 32465, 35753, 36582, 36681, 37802|
Description Jesse Glick 2003-08-29 01:05:56 UTC
I would like to work on having Nodes and also Looks run in the EQ only, like GUI components. This could also permit the Visualizer layer to be dropped and deprecated - Explorer views directly displaying nodes (or in the future, looks).
Comment 1 Jesse Glick 2003-08-29 03:49:10 UTC
Creating a branch: cvs rtag -b -r BLD200308280100 nodes_eq_35833 openide_nowww_1
Comment 2 Jaroslav Tulach 2003-08-29 08:19:14 UTC
This could be your plan: Whole visualizer framework is thankfully build around Visualizer.findNode and Visualizer.findVisializer methods. It should be enough to rewrite these methods to "work better". That means to somehow let LookNode specify that it will never change its structures outside of event thread (node insteanceof TreeNode, node.getValue ("javax.swing.tree.TreeNode"), node.getLookup().lookup (TreeNode.class), node.getChildren () instanceof TreeNode) and in such case just return the treenode provided by the node from Visualizer.findVisualizer method. I think this should be solved in relation with the lightweight children implementation (issue 32708) leading to small implementation of LookNode displayed in explorer without the need of visualizer framework. Also we should get closer to our goal of not initializing all children when only some of them are needed and prepare for that.
Comment 3 Jesse Glick 2003-08-29 16:09:55 UTC
Re. Visualizer and LookNode - interesting idea. I was actually planning on not giving special treatment to LookNode, but just dropping visualizers entirely, and having the explorer views directly use Node's as the tree objects (they do not need to impl TreeNode if you write it correctly), and ensure that all Node/Children operations happen in EQ. Re. lightweight children - I am going to take a look at that for sure; maybe merge those changes into my branch, I don't know. But I am interested in fixing threading behavior for all Node's, not just LookNode's. Re. not initializing all children when only some are needed - perhaps, although this doesn't seem like an urgent need: if the Node's are relatively light-weight to begin with, then constructing them is not such a big deal. In the longer term we could just display Look's directly, and the Look interface doesn't have this problem (since there is no necessary per-node state besides the underlying model).
Comment 4 Jesse Glick 2003-08-29 17:26:35 UTC
I just merged in the patches from issue #32708 into my branch, will examine further.
Comment 5 Jesse Glick 2003-09-30 21:07:29 UTC
Merging from BLD200308280100 to the new base tag BLD200309300100.
Comment 6 Jesse Glick 2003-10-09 04:41:26 UTC
Merged to new base tag BLD200310090100.
Comment 7 Petr Nejedly 2003-10-13 16:10:20 UTC
"Re. not initializing all children when only some are needed - perhaps, although this doesn't seem like an urgent need: if the Node's are relatively light-weight to begin with, then constructing them is not such a big deal." As long as the Node is really lightweight, we can create them an-block, but they aren't: * "normal" node have to pass real Children impl to the superctor at least. For LookNode, it means creating a lookup and asking the isLeaf method. * LookNode resolves things like Look and Selector during LN construction, which is expensive as well. From my measurements, creating a LookNode over a FileObject using a few FSExt Looks takes >4ms on the 2GHz notebook (when not temp throttling, if the temperature is higher, it takes over 20ms). I've not profiled it yet so I don't know the distribution, but try using LookNodes over a simple array with 10000 Integers or something like that... If we can make a LookNode really a lazy wrapper over the object with the rest of initialization on demand (don't resolve selector for children, don't ask for LookupItems unless isLeaf really uses the passed lookup, don't even call isLeaf for invisible nodes, ...), we can afford to create all the Nodes. Otherwise, we have to go different way, e.g. extend the API of Children to allow asking for individual children without initializing the whole list.
Comment 8 Petr Nejedly 2003-10-13 17:33:50 UTC
OK, I've fixed one my fault in the LookNode changes (the LookNode was prepared to not ask for LookupItems too early but my mistake have forced it to ask), so the LookNode construction takes now several hundred micros, but still too much to create 10000 of them.
Comment 9 Jesse Glick 2003-10-14 23:30:29 UTC
BTW: to better support direct node rendering in a tree, I have added in the branch to Children: public Node getNodeAt(int i) throws IndexOutOfBoundsException; public int getIndexOfNode(Node n); which seem pretty harmless (default impls exist of course) and could probably save overhead in a big tree.
Comment 10 Petr Nejedly 2003-10-20 15:23:30 UTC
After unprivating few methods (made them protected) I was able to implement special Children which are lazy enough (don't create things not asked for) yet still working correctly (manage correct event notification). I've committed the necessary changes in nodes and explorer into the branch and also used the Children from the LookNode. So Looks on the branch may still evaluate all the represented objects (only during event computation) but create LookNodes only when necessary.
Comment 11 Jesse Glick 2003-10-20 15:35:43 UTC
Sounds great! Please update http://core.netbeans.org/proposals/threading/looks-nodes-eq.html#apichanges accordingly.
Comment 12 Petr Nejedly 2003-10-21 15:00:46 UTC
Updated with changes to nodes package. The change in Looks was implementation detail :o)
Comment 13 Petr Nejedly 2003-11-20 15:13:05 UTC
Merging from BLD200310090100 to the new base tag BLD200311191900. Wouldn't it be better to just raise the base tag along the untouched trunk sources instead of merging trunk changes to the branch (forking in fact unaffected files)?
Comment 14 Petr Nejedly 2003-11-20 15:19:02 UTC
Of course started already ;-)
Comment 15 Jesse Glick 2003-11-20 16:46:19 UTC
You could try to move the tag on unmodified files, if you feel comfortable enough with CVS to try this. Much easier to screw up however.
Comment 16 Antonin Nebuzelsky 2008-02-08 15:04:49 UTC
Reassigning to new module owner Tomas Holy.
Comment 17 Jaroslav Tulach 2008-02-11 14:18:30 UTC
Imho, won't fix at least in the state of original proposal.
Comment 18 Jesse Glick 2008-02-13 20:25:13 UTC
Pity; it made Nodes significantly simpler.