Well put, Andrew. I'm looking forward to the response.
--jon
> Date: Sun, 7 Nov 1999 11:18:22 +0000
> From: Andrew Moulden <[EMAIL PROTECTED]>
> Subject: Re: Using behaviors... Behavior.postId() example
>
> Doug Gehringer wrote:
>
> >To review:
> > -- If you are making a single change to the scene graph, you can >just
> > make your change from your UI event handling code.
> > -- If you are making several changes, then you may want to use
> > Behavior.postId() to group your changes into a single frame.
>
> Doug,
>
> I'm not sure I understand you on this. Could you explain in more detail
> how J3D is synchronizing data between J3D's behavior thread and other
> threads (primarily the AWT event thread) ?
>
> In the example you've given and in messages you've made in the past
> you've been speaking about 'synchronizing' the J3D renderer to avoid any
> frame discontinuities i.e. it's *preferable* (but not mandatory) to
> handle scene graph changes in J3Ds behavior thread so that all scene
> graph updates are handled inter-frame and no visual anomalies will occur
> due to a Canvas3D being rendered before all input events have been
> processed.
>
> You seem to be advocating that it's okay to directly update a scene
> graph from a UI (and presumably therefore from a network) providing it's
> a single operation. However, I can't see how this can be so unless it
> can be guaranteed that the operation is atomic. Surely it's a
> *requisite* if you want a J3D app to be thread safe to post scene graph
> changes as either a behavior or into some sort of synchronized event
> queue (accessed in the postSwap() method of Canvas3D for example)?
>
> By the same token surely it's not possible on thread safety grounds to
> simply update a GUI control (even a simple JLabel) directly from the J3D
> behavior thread as you have done in your code? The Java Tutorial and
> Swing documentation go to great lengths to explain why such operations
> should be handled from within the AWT event despatching thread, so I
> would have thought that UI updates need to be handled either by using
> the rather awkward SwingUtilities.invokeLater() protocol, or by writing
> your own event class which extends AWTEvent and implements ActiveEvent
> so that the event will be processed through the dispatch() call (equally
> messy unfortunately).
>
> J3D is unusual in that it uses it's own event thread rather than the AWT
> event thread for input handling. Granted, the AWT event thread was
> originally designed for UI purposes, but practically every Java API now
> sees it as the core event thread (the Java API docs now call it 'the
> event thread'). So in writing Java3D apps, the synchronizing of data
> between these two main input threads becomes a core issue, though I
> can't find any mention of it in the official literature.
>
> It may be of course that you've got some underlying mechanism which is
> guaranteeing thread safety. If you were somehow locking on the AWT event
> thread (a very dubious solution I ought to add) during behavior
> processing then we'd be okay, but a simple test shows this isn't
> happening. Alternatively, you could be synchronizing data (transforms
> etc.) inside J3D in ways we can't see, but this would be very expensive
> computationally and may subvert JIT optimization.
>
> In short, it's very easy to write test examples which either crash the
> VM or corrupt scene graphs/GUI displays by allowing code running in the
> AWT thread to directly call into J3D, or vice versa. I'm sure there will
> be many who will say 'well, we've been making scene changes from button
> presses for months now and have never had a problem' but this isn't the
> point. Computers are so fast that the chances of two unsynchronized
> threads occupying the same method block and modifying data in an
> unpredictable way can be millions to one. The fact is however that such
> code is inherently flawed, and I know from bitter experience that the
> bugs it introduces are the most insidious you'll ever come across.
>
> Andrew Moulden
>
____________________ Peculiar Technologies ____________________
Jon Barrilleaux 3800 Lake Shore Ave. Purveyors of
[EMAIL PROTECTED] Oakland, CA 94610 Alternate Reality
510.444.4370 voc Augmented Simulation
510.444.0231 fax www.augsim.com and 3D Solutions
===========================================================================
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".
