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.
> The delay gets much worse when I have a set of satellite images in > there. Maybe ImageRendererJ3D will help with that? It might. > > 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)? Not that I know of, but I don't have any experience with more than about a dozen ScalarMaps. > 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? Like I said, a Control change should only retransform Data that include the Control's ScalarMap's RealType. If something else is happening, it would be useful to check whether you are re-autoscaling every time (which will trigger retransform of all Data in the Display). > 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. :-) We do this in Vis5D, which is easier because Vis5D has essentially a fixed MathType and fixed set of ScalarMaps. It could be done for VisAD by writing custom DataRenderers. There's a partially-done tutorial on this. Good luck, Bill
visad
archives: