Re: Weird display problem

• To: Tennessee James Leeuwenburg <tjl@xxxxxxxxxx>
• Subject: Re: Weird display problem
• From: Bill Hibbard <billh@xxxxxxxxxxxxx>
• Date: Thu, 18 Sep 2003 05:45:50 -0500 (CDT)

On 18 Sep 2003, Tennessee James Leeuwenburg wrote:

> I am now calling reAutoScale before adding references to any
> of my layers, and calling setContourControl after adding any IsoContour
> mappings, and there is no obvious effect. The code blocks are getting
> executed - I inserted some debugging output which is showing up fine.

Make sure you are calling reAutoScale() just before the
call to addReference() for your "SST-GLOBAL" model.

Also, make sure you are calling the setContourInterval()
method of the ContourControl for your ScalarMap
SST-GLOBAL-ST--SFC -> DisplayIsoContour (there is no
setContourControl() method).

> Also, this happens forever. If I remove the first model, the second one
> displays fine. If I then add the first model again (let's call it the
> third model now), I must remove the second model before the third will
> show up.
>
> I'm happy to try to strip the code down as far as possible, but I took
> out the most obvious GUI logic that could be interfering. Have you ever
> seen anything like this before? I mean, I have a lot of confidence in
> VisAD, so my gut says it's probably my fault, but I can't see anything
> obvious. Maybe you can suggest where things like this have happened in
> the past...

Unfortunately, I've never seen anything like this before.

> What seems interesting to me is that it seems to me like that data is
> being added to the display, but not being drawn. The "please wait"
> appears that I associate usually with the initial rendering of data to
> the display. The wait time after removing the first model until the
> second model's data appears is minimal.
>
> So it seems that VisAD is doing whatever work it needs to do to
> calculate whether the contour line displays should be, but not actually
> rendering them to the display.

Try uncommenting/modifying some debugging print statements
in DisplayImpl.doAction. Specifically at lines 1685-1686:

  System.out.println("DisplayImpl invoke renderer.doAction " + i);
  i++;

at lines 1693-1697 uncomment and change to:

     DataDisplayLink[] links = renderer.getLinks();
     System.out.println("transform " + this_transform + " " +
       + getName() + " " + links[0].getThingReference().getName());

and at line 1701:

  System.out.println(getName() + " invoked " + i + " renderers");

This will give you the names of the DataReferences and
DisplayImpls for which DataRenderers actually transform
data into scene graph depictions. Change lines 1693-1697
so it prints for all calls this_transform =renderer.doAction()
whether this_transform is returned true or false, and
prints the values of this_transform.

Another candidate for printing would be a new call to
System.out.println() inserted just before or after the
call to makeIsoLines() in the makeContour() method of
ShadowType.java. You'd print the values in the levs and
lowhibase arrays, and scale_ratio.

You can send us the output from these print statements
(along with an explanation of which DataReference names
go with which model).

If this doesn't enable us to solve the problem, then we'll
need to start printing all sorts of information from inside
VisAD. This can get very complex. There are two ways to
proceed:

1. Someone at BOM could become an expert in the internal
workings of VisAD and learn to track the display logic. The
starting point would be the DataRenderer tutorial, then a
dialog on visad-renderer. This would be a big commitment of
someone's time.

2. You could send me any necessary jar and data files to run
your system and duplicate the problem on my machine. If you
can duplicate the problem with something simpler than your
whole system, that would be good. I don't need the source for
your system, since my debugging would all be from within VisAD.

Cheers,
Bill

• Follow-Ups:
  • Re: Weird display problem
    • From: Tennessee James Leeuwenburg
  • p.s., Re: Weird display problem
    • From: Bill Hibbard

• References:
  • Re: Weird display problem
    • From: Tennessee James Leeuwenburg