Eike,
If you are updating the scene faster than the frame rate,
calling GC mamually will not help. The reason is that j3d has a
memory manager for recycling objects to minmize GC, but this
manager is a little too greedy. Here is the bug report, and it
apply to all scene update operations :BugId : 5011160 - setCoordinate memory leak.
PS: What will you gain from updating the scene faster than the
frame rate ? Java 3D can't be too smart, it has no apps.
knowledge. The apps. developer has to be on the driver
sit. :-)- Chien Yang
Java 3D, Sun Microsystems Inc.
Eike Tauscher wrote:
Yes, I've tried to call the GC manually - with no result. I've stopped at the moment the Java3D part, because the memory usage is too high. Probably I can improve the code, but I will have in the final model something like 5000 objects. JOGL has a footprint with same objects of 25MB instead of 70MB. I've just tested it. Maybe, I can provide some little code example, but therefore I need time. I will try to do so tomorrow.
I hope instantly the things will go better for Java3D if it goes to Open Source. It wars too long quite about this matter. All people I know stopped to go on with Java3D. It works fine, if you have to do only little things, but if you want to go deeper inside, it seems to be too bugy.
But now is hope!
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 17:22 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] AW: [JAVA3D] AW: [JAVA3D] What happened?
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".
=========================================================================== 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".
