Raj, I think that you can do what you want to do in a Behavior.
The structure I proposed was a subclass of Behavior that implemented the Listener for your Swing component(s). In the Listener's action method, your class sends a PostId() to itself. Your class has been set to wakeup on PostId, and its processStimulus() wakes up and does your geometric calculations (effectively hogging most of the Java 3D compute time, freezing rendering). User interactions from the triggering Swing component are disabled during this time because you don't reset the PostId wakeup alarm until just before you exit processStimulus() after you're done with that set of computations. If there are other critical GUI interactions you want to freeze, you'll have to reset the other Behaviors (assuming you've given them the same type of Listener/PostId setup.) But even if you don't block them, they won't affect your then-current calculations because their events won't get processed until after you exit processStimulus(). I frankly don't know how or whether wakeups stack up when the alarm isn't set, and I don't know how to flush the queue if they do. It'd take some experimenting to figure that out. The point of setting the Java 3D thread priority is to prevent the unrelated GUI and system services from becoming too sluggish. hth, Fred Klingener ----- Original Message ----- From: "R Vegan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 02, 2002 12:59 PM Subject: Re: [JAVA3D] On Threads ( And a Happy 2002 EveryBody ) > Hi Todd and Fred and the Rest of the Thread Gurus: > > Thanks very much for your ideas on this subject. > > Todd ! The idea of throwing up a modal dialog to block > the user from doing anything while the system is busy > number crunching is appealing. In cases where the app. > is not MT safe, one could simply run the computations > on the Swing's event dispatching thread. However, if one > spawns off a new thread for the computations then there > is the danger that the GUI becomes active again for some > other input from the user; input which could potentially > mess up the computations in the newly spawned thread. So the > modal/progress monitor ploy will be effective in this > situation. The question though that remains is whether > setting up the thread priority is platform independent. > > Fred ! I sieved through the archives and got hold off > the snippet on thread priority by Kelvin that you had > mentioned. Thanks very much for the info. So as to be > able to starve all J3D threads during the geometric > computations, this is what I did inside the button's > actionListener: > > // first save the current thread priority ( whatever it is ) > int oldPriority = virtualUniverse.getJ3DThreadPriority(); > > // next assign low priority to J3D Threads > virtualUniverse.setJ3DThreadPriority( Thread.MIN_PRIORITY ); > > // now call here the method which does the > // intensive numerical comps. > invokeMyNumerics(); > > // reset the J3D thread priority to its saved value > virtualUniverse.setJ3DThreadPriority( oldPriority ); > > OK ! the code compiled and ran fine. BUT the CPU time > for my numerics remained virtually the same. In other words, > starving the J3D threads did not speed up my numerics. > Could the reason be simply that the J3D threads were in fact > not a bottleneck at all in the first place ? Or I am doing > somethin' goofy ! > > Let me know when you folks get time > > Regards > > Raj Vaidya > > > > > > > > > >On Fri, 28 Dec 2001 12:49:44 -0700, Raj Vaidya <[EMAIL PROTECTED]> wrote: > > >To All Ye Thread Gurus: > > > >Is fiddling with threads worth the trouble in a Java3D App.? > > > >For example, at the click of a Swing button my app. does > >very highly numerically intensive computations to create > >a geometry and subsequently makes it *live*. At the time > >when the geometry is being created, I would like all > >CPU resources to be dedicated to just that and minimally, > >if at all, to anything else. Would the resources allocated > >to the various threads(?) ( viz. Swing thread, the Java3D > >renderer thread, behavior threads etc) grossly affect that > >allocated to numerical computations (FLOPS). If so, are there > >safe/adventurous ways of handling the problem with/without > >regard to portability ? > > > >Any ideas welcome !!! > > > >Happy New Year Everybody > > > >Raj 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".
