--On 10/25/00 03:52:31 PM -0400 Shawn Kendall <[EMAIL PROTECTED]> wrote:
> First, thanks for the more detail explanation.
>
> Joe Kiniry wrote in a non-Java3D-interest mail:
>
>> Because Java3D guarantees that rendering is halted during execution of a
>> behavior's processStimulus() method we can guarantee that (a) the
>> computation thread gets put in the run queue next and (b) that the
>> rendering thread waits until it is signaled that computation has
>> completed before rendering a new frame.
>
> Second, what is your source for; "Java3D guarantees that rendering is
> halted during execution of a behavior's processStimulus() method"? Is
> it in the API docs somewhere?
I haven't cross-referenced with the "specification" or API, but in the
message from Kevin Rushforth <[EMAIL PROTECTED]> on Thu, 28 Sep
2000 13:02:51 -0700 he states:
"The current Java 3D behavior system guarantees that all scene graph
updates that occur from within a single behavior will be reflected in the
same frame."
If there were only a single thread in Java3D, then this result is obvious,
i.e. blocking a thread in a behavior would mean no rendering could possible
take place.
If Java3D has multiple threads (at least one for behaviors and at least one
for rendering) then the situation is a bit more complex. Assuming thread
priorities are equal (which is a whole 'nother ball of wax), the only way
that they can make this guarantee is if the rendering thread(s) guarantee
that a new behavior will not be triggered until the current frame has
completed (i.e. block the behavior thread(s) when they return from a
processStimulus() until the current frame is rendered [equivalent to saying
the current scenegraph is walked]). If this were not the case, any newly
triggered behavior could make further modifications to the scene graph,
thus invalidating this claim.
Thus, if the behavior in question is triggered on WakeOnElapsedFrames(0),
and given the guarantee on such a behavior, then the rendering system
*must* render a single frame and then trigger the behavior.
Of course, all this is presuming that the rendering engine doesn't make a
snapshot of the scenegraph per frame. I presume we can all agree that such
an implementation would not have reasonable performance.
I'd provide further cross-references from the list but the web front-end of
the listserver has been saying "Error - unable to initiate communication
with LISTSERV (errno=145). The server is probably not started." for the
past several days. You'd think that no one at Sun used the server nor did
they have any automated maintenance running on/for it.
> Several developers, including myself, have posted about this many times
> before. The official response from the Java3D team was that Java3D does
> NOT synchronize the render and behavior threads and will not because the
> API spec does not specify that it should. I myself was just posting code
> to the Java3D team yesterday that showed more problems with this.
>
> The only ways I know of to make sure that your updates are atomic and the
> not concurrent with the render thread is in the GeometryUpdater interface
> for GeometryArrays or stop the thread yourself. Perhaps, I have missed
> this.
>
> Can someone on the Java3D team please address this as soon as they can,
> and perhaps post the thread organization once and for all?
I have not investigated the use of GeometryArray yet, so I cannot comment
on the above.
We, too, would love more details on thread usage and performance tuning for
Java3D. Given all the strong words from Sun on Java3D's
performance-centric nature, developers really need stronger specifications
of these and related issues.
Finally, note that I'm on the digest list, so my replies will typically
have 24 hour lag; pardon any redundancy or the like. I simply don't have
time to keep up with the list during the day.
Joe Kiniry
--
Joseph R. Kiniry
DALi, 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".
