XmContainer (exapnding and collapsing nodes)

This forum is read only. No new submissions are accepted.

Questions about motif? Contact us

3 posts / 0 new
Last post
XmContainer (exapnding and collapsing nodes)

Submitted by Anonymous on Mon, 02/11/2002 - 23:36. Developers
Hi,

I`m using a Container to display a large number of objects (a few 1000s)
arranged in hierarchy. I needed to be able to expand/collapse all the
nodes in the hierarchy up to a certain level, e.g. display all nodes up
to second level in the hierarchy. I used a push button and in its
callback, I used XtVaSetValues() to change the XmNoutlineState for
all the nodes (in reverse depth-first order, ie expand children before
their parents).

The above works okay, the problem is the speed.

I was first using XmDETAIL, the expand & collpase up to the first 2
or 3 levels were ok (a few seconds) but if I go more than this it takes
a really long time (a few minutes). I switched to XmOUTLINE and found
that it is much (orders of magnitude) faster, but still relatively slow
to an average user. (FYI, I`m using a Sun Ultra10 and this is the
only user application running on it, so the delay would be even worse
when the load on the workstation is more realistic).

It seems to me that every time XtVaSetValues() is called, the whole
container is redrawn. Is it possible to freeze requests for redrawing
until I`m done using the container and then issue a single expose request?

I tried to use my own event loop

XEvent event;

for(;;) {
XtAppNextEvent(&event);

printf("Event %d
", event.type);

XtDispatchEvent(&event);
}

however, I found that during the time when the tree is being expanded, no
new events are generated! Isn`t the drawing code executed in the
event loop?

I have another program written in Java that uses the JTree component
with a similarly large number of tree nodes, and it works a lot
faster than XmOUTLINE. So I believe it should be doable in motif,
I don`t know how exactly though.

I apologize for the lengthy message.

Regards,
inas

ICS_support

A common trick which may work here is to unmanage the XmContainer itself, make the state changes, and then remanage the XmContainer. The idea is that the internal code manages data changes without needing to redraw the nodes. Then the tree is redrawn once when the XmContainer is remanaged. There will be some sort of delay -- either while all the state changes are being handled or while the new tree is being redrawn -- but the total shouldn`t be as much as you`re experiencing, with multiple wasted redraws and calculations.

You could probably get a similar effect by withdrawing the root node, making changes, and then having it displayed again.

And the JTree is likely more efficient anyway!

Anonymous

Thanks dbl for your reply. I have actually tried to unmanage/manage the container before I wrote here, and it didn`t make much improvement.

After many experiments, I decided to just use XmOUTLINE instead of XmDETAIL. The OUTLINE with long formatted labels looks similar to DETAIL and is much faster.

Unmanaging the nodes at the root level only, messes up the whole structure of the tree and state of outline buttons, i.e. the buttons appear as if the node is expanded when none of its children are visible.

Thanks.