Chien, Thanks for the explanation what happens. I change the transformation inside a mouseDragged method. So, about 16 TransformGroups (in my test case) are called on each mouse movement. This can't be handled so fast inside Java3D and the queue is growing (I suppose, the whole Transform3D object will be stored for each change). This should not be a problem, if Java3D would give this memory back after handle the events. But it doesn't. The memory footprint does not go down...!? But my 3D objects are at the right place and it works in real time! So, the events are all handled... but where is the memory? I will have a further look on my code, may be there is something wrong - will create a test case and post it...
Sadly I can't do it inside a Behavoir class (I must think about that but ...). I could change my code to set the TransformGroup only after finishing the movement. But for my application it isn't nice. And I still wonder if it will be a solution for the problem. The out of memory will come! Later - but it will. I don't want to provide a Button for recreate the scene graph - it is too much Microsoft solution for me... Best regards Eike >>>>Eike, >>>> Without seeing your program, here is my guess to the problem you >>>>having. >>>> >>>> In general, Java 3D operates via message passing.Imagine >>>>you have a user thread, that isn't bounded by the j3d frame rate, >>>>transmitting TG change requests to j3d. It is very likely that the user >>>>thread is running at a much high rate than your system j3d frame rate; >>>>often can be a million times greater. In such situation, a huge backlog >>>>of messages is created in the j3d's message queue, hence consuming >>>>memory. This is very bad for performance and a potential cause to "Out->>>>Of-Memory". If possible, the best approach is to do the scene update via >>>>j3d's behavior, which is in sync. with j3d frame rate. >>>> >>>>- Chien Yang >>>> Java 3D, Sun Microsystems Inc. >>>>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. =========================================================================== 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".
