NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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 | *----------------------------------------------------------------------*
visad
archives: