Re: change color optimization

Adding a setRange call to my ScalarMap to RGB does indeed seem to take
care of it! So, is that a bug or a feature?

On a related note, I get similar delays when I have non-null image Data
added to the Display but with the DataRenderer toggled off. If I toggle
the Data on then back off, all is well. Also, that first toggle on is
slow (with "please wait"), while additional toggles are fast (usually -
sometimes I get the delay toggling it on but I haven't found a
reproducible case, yet). Also, the auto axis scaling isn't applied until
the first toggle on. Is that by design (e.g. faster startup)? Maybe
using setRange to disable autoscaling will help this also. The jury is
still out.

Thanks,
Doug

P.S. I still haven't found the source of the setRange memory leak, but I
should be looking at that soon. Maybe it is related?

Bill Hibbard wrote:
> 
> 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.
> >

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