Re: [Update REQ 5322]: geomview usage stategy

["Stuart Levy" <slevy>]

> i dont think i can use this stradegy as i dont know ahead of time which
> objects can be grouped, and in principle every atom may need to be
> displayed individually at some point.

Here's the kind of thing I mean in a little more detail.  I'd been assuming
you loaded each atom into a "handle" the first time it was needed, with maybe
  (hdefine geometry atom1138 { INST transform ... geom < blob.oogl })

and then made it and all its hundreds or thousands of cohorts visible
with something like
  (geometry ice { LIST { : atom15 } { : atom23 } ... { : atom1138 } })

Is that how you do it?  Since you say you don't believe the update-scanning
argument, maybe you're just using one "(geometry ...)" command per atom, as in
  (geometry atom15 < blob.oogl) (xform-set atom15 ...)
  (geometry atom1138 < blob.oogl) (xform-set atom1138 ...)
  
In that case, you're right; the limiting factor is probably the X/Motif
code for maintaining a list of items in the browser.  It seems to spend
a great deal of time there even if the panel is turned off, and I wouldn't
be surprised if the time to add an entry is proportional to the number of
entries in the list.

At the other extreme -- which I'd guessed you had taken, at first -- you
could have just a single object in the browser, a LIST containing all the
visible atoms, and update it at each step to mention everything which should
be visible.

Anyway, one kludgy approach which might help would be to define a batch of
handles, one per atom, using "(hdefine geometry atomname { ... })".
These will form a library of geometric data, invisible until you
attach them to something in geomview's object browser with (geometry ...)
commands.

Now, suppose you want to not-too-inefficiently make some subset of the N
atoms visible.  Suppose you apportion K ~ sqrt(N) atoms to each of M ~ sqrt(N)
geomview-browser objects, with atoms 1..K being displayed (if ever) as part of
clump1, K+1..2K in clump2, ..., atoms N-K+1..N in clumpM.
The clumps have no particular graphical significance, they're just a way
to induce geomview to order the data structures more efficiently.
Given this, you could write something like the following almost-C code:

   printf("(progn ");	/* Begin group of commands to be executed together */
   for(clump = 1; clump <= M; clump++) {
	printf("(geometry clump%d { LIST ", clump);
	for(atom = (clump-1)*K+1; atom <= clump*K; atom++) {
	    if(this atom visible)
		printf("{ : atom%d }", atom);
	}
	printf("})\n");
   }
   printf(")\n");	/* end of group */

You could likely optimize this further, not re-defining clumps whose visibility
hasn't changed since the previous display update.

I know this is awkward, but it's the best we can offer out of the box.
I should also say I haven't tried this -- I only suspect it might help.