Re: [Fwd: AnimationControl - turning animation string on/off.]

[Bill Hibbard <billh@ssec.wisc.edu>]

Don,

You have a good point about discontinuity of this function
when the ScalarMap to Animation is destroyed / created.

I'd be interested to hear what Jim and others think about
your alternative.

Bill

On Tue, 10 Jun 2003, Don Murray wrote:

> Bill-
>
> Bill Hibbard wrote:
>
> > Thanks. Nice to see that you were able to accomplish the
> > same thing by an extension of DefaultDisplayRendererJ3D.
>
> Seems like overkill to have to do this, but it worked.  And
> I will probably use this in the future instead of the
> AnimationControl changes for the reasons I state below.
>
> > Since I've already committed Jim's code, since it makes
> > this functionality accessible without any class extenson,
> > and since AnimationControl is a natural and more specific
> > place for this logic, I'll stick with that.
>
> Actually, I think DisplayRenderer is the more appropriate place
> for this since it is something that the DisplayRenderer controls
> just like the VisAD Box and the cursor string and it's the
> DisplayRenderer subclasses who actually have to render the string,
> not the AnimationControl.  And my suggested changes to DisplayRenderer
> (e.g., setAnimationStringVisible) do not need any class extensions.
>
> Every display has a DisplayRenderer which controls this globally
> and you can easily toggle it on and off at the Display level.
> If you call clearMaps() on the display and then add back in
> ScalarMaps, including one to Animation, then the enabling/disabling
> of the animation string is not persisted/carried along.  You have
> to manually go back and reset it to what it was before.  However,
> if you had methods in the DisplayRenderer to enable/disable the
> drawing of the animation string, when the ScalarMaps are removed/added,
> it would just keep the same state as before.  Just one less
> housekeeping item to keep track of and it is more logical to
> have the DisplayRenderer which draws the string by calling
> getAnimationString() decide whether or not to draw it.  And
> it only requires modifying one class (well two if you want
> to add it into RendererControl).
>
> When VisAD was being developed, the model was that you
> set up your entire display, added in all ScalarMaps, added
> your data, set all parameters on controls and never changed
> a thing.  That's how most of the examples and the collaborative
> stuff works.  In practice, VisAD has developed beyond that
> model, where ScalarMaps and controls are added/removed by
> user interactions in UI's.  Applications like the IDV take
> advantage of this evolution.  As VisAD continues to develop,
> this new model should be used when deciding where to add
> enhancements.
>
> Since the code you checked in is only in the untested stuff,
> it would be easy enough to back out of (that's what CVS is
> for).  Jim (and other renderer-list people), what do you think of
> this approach?
>
> > Jim, new variables in subclasses of Control should be
> > incorporated in the equals() and syncControl() methods.
> > I've done this for showAnimationString.
>
> Don
> *************************************************************
> Don Murray                               UCAR Unidata Program
> dmurray@unidata.ucar.edu                        P.O. Box 3000
> (303) 497-8628                              Boulder, CO 80307
> http://www.unidata.ucar.edu/staff/donm
> *************************************************************
>
>
>