NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
visad archives: