Yes, this is called message compaction and j3d did use this technique for the case of TG update. But doing this inside j3d will not totally eliminate the problem as j3d's threads are bounded by the frame rate., esp. when the TG message rate >> the frame rate.
- Chien Yang Java 3D, Sun Microsystems Inc.
N. Vaidya wrote:
Good point ! you're thinking of something like a queue where messages get stacked and only the latest one is grabbed between frame updates and then the queue is cleared up ? My guess - just a plain guess - as to why such a thing hasn't been conceived is probably because separate queues don't exist for the various kinds of updates so that you could selectively grab some and ditch some.
Again this is purely a guess.
On Wed, 14 Apr 2004 21:32:55 -0000, Michael Pfeiffer <[EMAIL PROTECTED]> wrote:
Also when these updates are triggered external - why could it be useful to handle more "gestures" than can be displayed? If these data aren't used anywhere else this sounds a little bit like wasting computing power. And in case they are used elsewhere wouldn't it be possible to compute all data but to use less amounts of them for displaying with J3D? Couldn't that be an interesting optimization of the code?
Michael
On Wed, 14 Apr 2004 12:47:20 -0600, N. Vaidya <[EMAIL PROTECTED]> wrote:
Eike's updates are made by user gesture. Wonder if he could be doing that continuously at a rate faster than the FPS to produce a ~20MB leak. The diagnosis for the problem mentioned in his e-mail link does seem to be correct.
Agreed a testcase would help !
Regards
Vaidya
On Wed, 14 Apr 2004 11:31:55 -0700, Chien Yang <[EMAIL PROTECTED]> wrote:
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:
memory...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
usage increases. If there 10 points moving at the same time (withText3D
labels)... 20MB and growing.problem,
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
====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 thebody
toof the message "signoff JAVA3D-INTEREST". For general help, send email
[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".
=========================================================================== 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".
-- http://www.3dchat.org - Welcome To The Unreal World http://java3d.virtualworlds.de - The J3D Developers Ressource
========================================================================== 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".
