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 |
*----------------------------------------------------------------------*
