Re: a visad app/applet that behaves in ways I don't understand

• To: "Alexander, Ben" <BAlexander@xxxxxxxxxx>
• Subject: Re: a visad app/applet that behaves in ways I don't understand
• From: Dave Glowacki <dglo@xxxxxxxxxxxxx>
• Date: Fri, 06 Oct 2000 17:01:45 -0500

Dave Glowacki wrote:
> "Alexander, Ben" wrote:
> > My problems started 
> > when I tried to replicate a user's typical use of our program (i.e. generat
e
> > data, plot data, repeat).  My 
> > applet works beautifully the first time, but won't show any plots on
> > subsequent invocations.  To investigate
> > this behavior, I modified my program so that it could also run as an app.
> ...
> > One additional note: the app _sometimes_ works correctly without any
> > modification (suggesting a
> > timing problem?).  I have never seen the applet generate a second plot,
> > however.
> 
> There's definitely a timing problem in the application, but I'm not
> yet sure where it's located.
> 
> It looks like the rendering for the first start() is interrupted
> by second start() clearing and reloading the data in the Display,
> and that's killing any subsequent rendering.
> 
> I've got to go right now, but I'll poke at this some more tomorrow
> and see what I can find...

I spent most of the day trying to track this down and from what I
can tell, this appears to be a Java3D bug.  At the time you start
the second set of init/start/show calls, no VisAD threads are
active.

The only thread that's active seems to be building the display
window.  When both programs finish, the working program has 4
extra Java3D threads which, for some unknown reason, are never
started if the data hasn't been displayed.

Just to confirm, I downloaded Java3D-1.2 and, while it has a
whole bunch of other problems, it does successfully display
your data twice.

In other words, your 'apfrm' doesn't appear to be a bug in VisAD
or even something we can work around in VisAD (since the bug is
happening somewhere in the depths of Java3D after we've handed
the scene off to the Java3D renderer.)

You *might* be able to work around this by waiting for the
display to stop sending DisplayEvent.FRAME_DONE events before
you update the display with new data.

Sorry I can't be of more help!