Bug 35833

Creating a branch:

cvs rtag -b -r BLD200308280100 nodes_eq_35833 openide_nowww_1

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.

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

I just merged in the patches from issue #32708 into my branch, will
examine further.

Merging from BLD200308280100 to the new base tag BLD200309300100.

Merged to new base tag BLD200310090100.

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

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.

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.

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.

Sounds great! Please update

http://core.netbeans.org/proposals/threading/looks-nodes-eq.html#apichanges

accordingly.

Updated with changes to nodes package.
The change in Looks was implementation detail :o)

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

Of course started already ;-)

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.

Reassigning to new module owner Tomas Holy.

Imho, won't fix at least in the state of original proposal.

Pity; it made Nodes significantly simpler.