Hi Kelvin, Thanks much for the response. I went thru' the docs and my tests again, and I am still at sea. I'll try to get a testcase if you don't find any flaw in the logic below.
Let's say that at time 1:00 AM I invoke view.setMinimumFrameCycleTime to specify a frame cycle time of 10 minutes. This means that between 1:00 and 1:10 there will be no new frames rendered. Next, at time 1:01, I create a subgraph and make it live. This subgraph will be invisible for reason above. Finally, at time 1:05, I invoke again the view.setMinimumFrameCycleTime to specify a time period of 0 ms. Well, what I thought would happen at this time was that my subgraph waiting to be rendered all this while will be immediately visible on the canvas. Am I correct in assuming so ? However, what I am observing is that the subgraph is rendered only at time 1:10. The behavior that I am seeing right now is plausible if: 1. setMinimumFrameCycleTime method locks for a period equal to the specified time period, and control passes on to the next statement only then. 2. every subgraph that is made live has a time stamp based on the current FrameCycleTime, and will be rendered only after that time period. Let me know where the goof is when convenient, Regards Vaidya >On Thu, 15 Aug 2002 10:56:00 -0700, Kelvin Chung <[EMAIL PROTECTED]> >wrote: >Raj N. Vaidya wrote: > >> Have been experimenting with the setMinimumFrameCycleTime >> method in the View class and having some problems in trying >> to get a handle on how it works and how best to use it. >> >> Essentially, I am going thru' the following sequence of >> steps from within the actionPerformed callback from >> a JButton: >> >> // step 1: >> // set the FrameCycleTime to a high value >> view.setMinimumFrameCycleTime(100000); // 100 sec. >> >> // step 2: >> // create a new GeometryArray+Shape3D+BranchGroup >> // and make live the new BG >> >> // step 3: >> // reset the FrameCycleTime >> view.setMinimumFrameCycleTime(0); // default value >> >> Possibly my experiments with the above logic may not have >> been exhaustive enough to draw any definitive conclusions, >> but this is what seems to happen: >> >> When I press the JButton, my canvas appears to remain in >> a state of lull for roughly 100 sec. before it updates >> itself to make visible the newly attached BG. And this >> happens even if the time taken by Step 2 is much less than >> the frame update period, i.e., 100 sec. So it appears that >> the FrameCycleTime value is not continuously polled to check >> if its value has been changed. >> > > >It is possible since when step2 the new scene graph make >live it is using the old setMinimumFrameCycleTime with 100 sec. > >Until the its value restore to default 0 rendering will >happen every 100 sec. > > >In your case you should try setting > >view.setMinimumFrameCycleTime(0) > >BEFORE >create a new scenegraph and make it live. > > >A small test case would be great if I misunderstand > >the issues here. > > > >> Alright, I may have have just accepted the above result for >> what it is if I hadn't in a moment of wild abandon completely >> commented out Step 2 and ran the app. in that trivial mode. >> And with that, surprisingly, the canvas came to life >> instantaneously without waiting for the full 100 sec. >> This seems to suggest that making live a BG during the >> frame update period somehow makes the View to remain >> unresponsive to the newly set time period. Is this along >> expected lines ? >> >> What I would have liked to see though is for the View to respond >> to the new time period as and when it is set, perhaps with a >> reasonable time lag for compilation etc. This would obviate >> the need for guesstimating a value for cycle time that would be >> optimally high under various conditions. >> >> As I said, my experiments may not have been thorough. Just want >> to get some quick ideas before I proceed further. >> >> TIA and Rgds >> >> Vaidya >> > > >- Kelvin >-------------- >Java 3D Team >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". =========================================================================== 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".
