Re: change color optimization

Bill Hibbard wrote:
> 
> Hi Doug,
> 
> > I have a bunch of station data with many time samples of each. I'm
> > displaying them with shapes ( time -> ((x,y,z) -> (color, shape)) ). I
> > use the "color" type to map to RGB. I give it a constant color by giving
> > BaseColorControl a table with a single color. Thus, I can easily change
> > colors of my shapes via the BaseColorControl. I map time to Animation to
> > get the sample I want.
> >
> > Unfortunately, if I change the color of one shape, VisAD seems to be
> > working very hard with everything in the display instead of only the
> > shape being modified. All the data in the display blinks during this and
> > is not pretty. It's not so bad without the Animation map, but it still
> > seems slow. I tried display.disableAction() before calling
> > control.setTable() but that doesn't seem to help.
> >
> > Any ideas how to optimize changing colors (and other properties via
> > controls)?
> 
> When a Control changes (e.g., a ColorControl.setColorTable()
> call), the unit of re-transform is each Data object under
> DataReferences linked to the Display (the only current
> exception to this is for time sequences of images using
> ImageRendererJ3D). 

The delay gets much worse when I have a set of satellite images in
there. Maybe ImageRendererJ3D will help with that?

> And every Data object will be transformed
> that includes the affected Real (in your case, every Data
> object that includes 'color').

The "color" type is unique for every Data object I have. So I am already
doing as you suggest. Is there a problem with having too many ScalarMaps
(e.g. on the order of 100)?

I don't see why changing the color table of one would affect the others.
It takes as long (and sometimes longer!) to make a change as it does to
initialize the whole display. It is as if everything is being
recomputed. Is that the case? 

I'm thrilled with the animation performance I'm getting now using the
AnimationControl approach. But the performance of changing properties
(e.g. color) stinks. I guess that is the tradeoff we make in this game.
However, it seems to me there is room for optimization. In addition to
the point above (seemingly unneeded computations), what about rendering
the visible time sample as soon as possible before cranking on
everything else? I think it is about time I learn some Java3D. :-)

Thanks,
Doug

-- 
*----------------------------------------------------------------------*
| Doug Lindholm, Software Engineer          |  E-mail: lind@xxxxxxxx   |
| Research Applications Program             |   Phone: 303-497-8374    |
| National Center for Atmospheric Research  |                          |
| P.O. Box 3000                             |     There's no place     |
| Boulder, Colorado 80307-3000              |        like $HOME        |
*----------------------------------------------------------------------*