>The way I understand it, the only way we're guaranteed that the
>rendering thread won't step on scene graph updates (or vice
>versa) is for us to complete all the scene graph updates in the
>processStimulus() method of an active Behavior.
Yes... Soon after I posted that message I tried changing my program so
that the run() method is called from inside a behaviour - this seemed to
fix the flickery jerkiness, although I'm still not really sure what
difference it made - all I really changed was that rather than calling
run() (with its while loop) from init() I called it from inside a Behavior
class. Still, if it works it works...
For what it's worth, Chien Yang's reply suggested the gc was likely to be
the real culprit, being provoked into action by reckless use of new
Transform3D objects etc. every frame - I'd already apparently fixed the
problem with a Behavior, so I don't know whether fixing this would have
helped without that (I'm not quite curious enough to go back and find out).
>Note that this is the approach recommended here a few days ago
>by Raffi Kasparian in "Controlling unpredictable motion" (giving
>an active Behavior a Runnable member, and run()-ing it in the
>Behavior's processStimulus() method.
Yes, but Paul Byrne suggested (off-list) that the only real trouble with
not using behaviours is that the result of multiple calls may not appear in
the same frame. I'm not convinced that was the problem here, since an
individual object seemed to be vibrating horribly...
- Fergus
http://fergusmurray.members.beeb.net/
geometrical applets a specialty
===========================================================================
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".
