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

[Tom Rink <rink@ssec.wisc.edu>]

Hi Bill,

I agree with Don: AnimationControl should only provide methods
to make a string of it's current state, the DisplayRenderer should
decide if to render the string into the Display.  There is the issue
of setAnimationStringVisible() when there isn't a ScalarMap to
Animation?

Tom

Bill Hibbard wrote:

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