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: >>>> >>>> >>>>> ...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". >> >> =========================================================================== >> 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".
