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 35833

Summary: EQification of Nodes and Looks
Product: platform Reporter: Jesse Glick <jglick>
Component: NodesAssignee: t_h <t_h>
Severity: blocker CC: jtulach, phrebejk, pnejedly, tor, ttran
Priority: P2 Keywords: API, THREAD
Version: 3.x   
Hardware: All   
OS: All   
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

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
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

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.