From: "Raj Vaidya" <[EMAIL PROTECTED]> Sent: Thursday, January 03, 2002 3:12 PM
> Hi Fred: > > Thanks again for detailing your approach. > > A behavior that implements ActionListener....very imaginative > I should say. It is a nifty pattern that I wish I had invented. :-) Alas, it's all there in the AWTInteraction demo in the Java 3D distribution. AWTInteractionBehavior.java shows the skeleton. There, they respond to only a single event, but the way is clear for you to respond to any (reasonable) number of events, set a different postId for each, then decode them in the processStimulus. The bookkeeping can get tricky, and the events that carry data with them (like JSliders e.g.) take some extra fiddling, but the gatekeeping control it gives you between the GUI and the scene graph makes it worthwhile. > Now I know what you meant by doing everything thru' > a processStimulus. Will try that once I read up and refresh my > memory on the postId() mechanics. > > A few clarifications though: > > 1. your structure would obviate the need for messing with the > the setJ3DThreadPriority() method, am I right ? Yes. The whole point is to do what you want without thread priorities. > This is > assuming that when the code enters the processStimulus > method of a behavior, that behavior automatically hogs > up all the resources I think that's overstating it a bit. If I understand Sun's guidance on this, you are guaranteed two things: 1.) that the rendering thread will wait for you to finish with your processStimulus(), and 2.) no other processStimulus() will start or run until you exit. I assume that all of the other j3d threads will run, but they presumably will run out of work to do if you have lengthy computations. These guarantees give you a handle on the first of your concerns - preventing the rendering of mangled geometries. The second - disabling user interactions during geometry updating - comes from the Listener / PostId pattern. > ( including that of Swing ? ). No. I'm pretty certain Swing and system services get their slices. > 2. To the extent that I am willing to do things off of > the Swing thread, shouldn't have my rought cut approach > using the SetJ3DThreadPriority() method starved all J3D > threads and speeded up my computations at least to some > perceptible degree ? This is what is quite baffling. > Does this J3D method really work under such circumstances > or have I misinterpreted the doc. I have to share your puzzlement. But then again, I've been going through a more or less continuous negative learming process on threads. Every time I try to fiddle something, I find out that things I thought I knew aren't true. I know an awful lot less now than I did when I started. I'll offer the following from Horstmann and Cornell, Core Java2, Volume II: TIP: If you find yourself tinkering with priorities to make your code work, you're on the wrong track... Platform dependence is enough for me to avoid them like the plague. Cheers, Fred =========================================================================== 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".
