Eike, Just to add to my previous e-mail....
I did read that you're not creating any new objects. But mentioned the GC because getting and setting the Transform3D probably creates copies. But I wonder if that would lead to a 20MB memory leak since you seem to be doing the updates manually. Vaidya >On Wed, 14 Apr 2004 09:22:23 -0600, N. Vaidya <[EMAIL PROTECTED]> wrote: >Have you tried invoking the GC ? - repeatedly and successively ? Though the >GC has a mind of its own, I've found that it usually responds if you coax it >well enough :). > >And about the e-mail link, and based on its findings with the profiler, I >can only surmise that there is either a genuine memory leak or there is this >issue of (rapid) updates from outside a behavior. May be the support team >can tell us if there is indeed a problem. > >Regards > >Vaidya > > > >>On Wed, 14 Apr 2004 16:09:14 +0200, Eike Tauscher <[EMAIL PROTECTED]> >>wrote: > >>...sounds interesting. I will try it, to get the memory back. Do you >>know something about the TransformGroup problem? I have created a basic >>class called Object3D sub-classed from TransformGroup. Inside a two >>dimensional view, the user can move a point (or more...), by dragging. >>The 3D shape of this point is a cube inside Java3D (using my Object3D >>class). If the point is moved, I set the translation according to the >>new coordinates. I don’t create new Objects but if I do this, the memory >>usage increases. If there 10 points moving at the same time (with Text3D >>labels)... 20MB and growing. >> >>I've found some similar inside the forum: >> >>http://forum.java.sun.com/thread.jsp?forum=21&thread=404881 >> >>Regards Eike >> >> >> >> >>-----Ursprüngliche Nachricht----- >>Von: Discussion list for Java 3D API >>[mailto:[EMAIL PROTECTED] Im Auftrag von N. Vaidya >>Gesendet: Mittwoch, 14. April 2004 15:18 >>An: [EMAIL PROTECTED] >>Betreff: Re: [JAVA3D] AW: [JAVA3D] What happened? >> >>Hmmm...I think it is something like this. >> >>Suppose I've a live BranchGroup which is the parent of a subgraph >>containing >>possibly other Groups and, in particular, Shape3D's with possibly many >>Appearances and Geometries. If I detach this BranchGroup then my >>experience >>has been that the memory corresponding to that BranchGroup and its >>subgraph >>components will not be released *until* you attach and detach another >>BranchGroup. And, of course, when you detach that second BranchGroup >>you'll >>again see a memory leak corresponding to that second BranchGroup. >> >>Now, this may not seem like a big problem since the memory is retained >>only >>between successive BG detaches. However, imagine a situation when apart >>from >>visualizing the geometry, I'd also be doing other memory allocations as >>part >>of a computational steering framework, for example, then it does become >>a >>big issue. The dummy attach/detach seem to be an effective workaround >>for my >>problem presently. >> >>I'm not 100% sure that this leak occurs in general with each and every >>BranchGroup, or, if it is a function of the various kinds of >>capabilities >>such as By_ref, U_C_I_O, etc. >> >>The general advice that I have from Chien, hope that I paraphrase him >>correctly and which may or may not be a fix for this particular problem, >>is >>to perform all BG detaches (and probably attaches too) from within a >>behavior especially if the attaches and detaches are very !!!rapid!!!. >> >> >>Vaidya >> >>=========================================================================== >>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >>of the message "signoff JAVA3D-INTEREST". For general help, send email to >>[EMAIL PROTECTED] and include in the body of the message "help". > >=========================================================================== >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff JAVA3D-INTEREST". For general help, send email to >[EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
