Hi Bill et al,
Adding display.disableAction() does not help in the MemoryTest example.
However, if the map is to RGB instead of XAxis, disableAction() stops
the leak.
Is there a good reason why disableAction() stops a RGB map setRange but
not a XAxis map setRange? I'd like to be able stop this leak with
disableAction on my non-visible displays.
Thanks,
Doug
Bill Hibbard wrote:
>
> Doug,
>
> I'm sure this Java3D bug report that Tom found is the cause
> of your problem. There is no good way for VisAD to compensate
> for this. However, your application can keep track of when
> its DisplayImplJ3Ds are not visible in a Frame, and refrain
> from calling ScalarMap.setRange() and other operations at
> that time. You may be able to avoid most operartions simply
> by calling DisplayImplJ3D.disableAction() when the display
> is not visible.
>
> Good luck,
> Bill
>
> Tom Whittaker wrote:
> >
> > I agree with Tom...I ran this on Windoz and the result was the same --
> > it just took longer to gobble up the memory...
> >
> > Given Don's observation that if the window is displayed, the leak
> > doesn't, well, leak, I cannot help wonder if this bug isn't related:
> >
> > http://developer.java.sun.com/developer/bugParade/bugs/4727054.html
> >
> > It says, in part:
> >
> > "Current architecture allocate message and send to MasterControl
> > every time an attributes of scene graph changed.
> > This is most like done by behavior thread.
> >
> > Under normal circumstance when window minizimize all Java3D threads
> > are put to sleep so there is no message passing in the system
> > from Behavior or other Java3D thread.
> >
> > However if there is a free running thread which continously change
> > scene graph attributes the message will continously accumulate in
> > the system and MasterControl thread will not wake up to process
> > any message. This result in out of memory after a while.
> >
> > It is not recommend to do so even though window is not minimize
> > since the thread may pump message to
> > java3d system too fast that java3d can't handle. Thus can dramatically
> > slow down the system. Besides, java3d can only change scene graph
> > as fast as the frame rate. So if the transform is changed 10 times
> > between each frame the first 9 time are ignored. The best way to
> > do so is to use behavior thread which gaurantee synchronized with
> > the Java3d system and frame rate.
> >
> > This bug will most likely mark "will not fix" later."
> >
> > tom
> > --
> > Tom Whittaker (tomw@xxxxxxxxxxxxx)
> > University of Wisconsin-Madison
> > Space Science and Engineering Center
> > Cooperative Institute for Meteorological Satellite Studies
> > Phone/VoiceMail: 608.262.2759
>
> --
> ----------------------------------------------------------
> Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
> hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
> http://www.ssec.wisc.edu/~billh/vis.html
--
*----------------------------------------------------------------------*
| 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 |
*----------------------------------------------------------------------*
