In the absence of more information, my guess is that
the null Data is causing an autoscaling failure on
at least one ScalarMap. This will cause all Data to
be re-autoscaled and re-transformed on every event
requesting any Data to be re-transformed (such as
your color change event).
If you can figure out which ScalarMaps apply only
to the null Data, you can explicitly call their
setRange() methods to tell the system it doesn't
need to autoscale them.
Good luck,
Bill
Doug Lindholm wrote:
>
> Here's an update on some performance issues.
>
> I have reduced my test case (within VMET, not yet stand-alone) to a
> satellite image (320x320) and two simple maps (roads, rivers...).
>
> Under normal circumstances, I can change the color of one map (e.g.
> rivers) and get results in less than one second. However, if one of the
> maps (e.g. roads) has null Data (i.e. ref.setData(null) added to the
> Display with a non-null DataRenderer), the color change of the good map
> takes much longer. During this delay, "please wait" shows on the
> display. It does not appear in the former case of no missing data. The
> delay is even worse if I'm using ScalarMaps of my axes types to
> SelectRange (to keep data from extending over the edge). I have test
> cases that take 18 seconds with a single null Data object but less that
> one second with non-null Data.
>
> Is there a bug in the way null data is handled? I haven't quite mastered
> the DataRenderer tutorial, but it smells like the DisplayImpl's doAction
> is being over zealous with doing the DataRenderers' actions.
>
> Thanks,
> Doug
>
> "From: Bill Hibbard " wrote:
> >
> > > 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
>
> --
> *----------------------------------------------------------------------*
> | 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 |
> *----------------------------------------------------------------------*
--
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
