< Zurück | Inhalt | Weiter >

Message processing and threading architecture


The MasterControl class is a message exchange mechanism between the various subsystems that compose the Java 3D runtime. The MasterControl thread maintains five UnorderList members, each containing Java 3D worker threads.


stateWorkThreads:

RenderingAttributesStructure calls updateMirrorObject on the

NodeComponentRetained passed with the message.

GeometryStructure maintains a binary hash tree of GeometryAtom objects and

Groups. Maintains the wakeupOnCollisionEntry, Exit, and Movement lists.

BehaviorStructure maintains a list of behaviors and marks them for activation.

RenderingEnvironmentStructure maintains a list of the lights, fog, alternate appearances, clipping regions, and backgrounds to be used for each RenderAtom.

SoundStructure maintains a list of sounds and soundscapes and schedules them for activation with the View’s SoundScheduler.

BehaviorScheduler, for all VirtualUniverse instances, maintains a list of BillBoard behaviors and behaviors in the system and calls the processStimulus method on each if marked for activation.

Inputdevicescheduler maintains lists of nonblocking and blocking input devices and calls the pollAndProcessInput method on the nonblocking devices. A new thread is created to handle the input from each blocking

InputDevice.

RenderBin, for each View, maintains lists of RenderAtoms that describe rendering operations to be performed. The RenderBin implements methods such as renderOpaque, renderBackground, renderOrdered,

and renderTransparent, which are called by the Render class.

SoundScheduler, for each View, maintains a list of SoundSchedulerAtoms and marks each for activation. The render method iterates the scheduled SoundSchedulerAtoms and calls the start method on each.

renderWorkThreads:

Renderer for each Canvas3D’s Screen3D. The Render class runs the main Java 3D rendering loop by calling methods on the Canvas3D class and processing the RenderBin for the Canvas3D’s View.

requestRenderWorkThreads:

Renderer for each Screen3D in the device render map.

renderThreadData:

Renderer for each Screen3D for each View, including offscreen Renderers.

inputDeviceThreads:

A single Inputdevicescheduler.

Each UnorderList member contains an array of J3dThreadData objects, containing a J3dThread

member and additional scheduling information.


The MasterControl.doWork method (invoked by the MasterControlThread.run method) runs in two phases. The first phase checks for any pending messages to be executed and returns if there is nothing to execute. The second phase runs the threads under the control of the MasterControl class.


void doWork()

{

runMonitor( CHECK_FOR_WORK, null, null, null, null); if(pendingRequest)

handlePendingRequest(); if(!running)

return; if(threadListsChanged)

updateWorkThreads(); updateTimeValues();

View aview[] = (View[])views.toArray(false); for(int i = views.size() − 1; i >= 0; i−−)

if(aview[i].active) aview[i].updateViewCache();

runMonitor( RUN_THREADS, stateWorkThreads, renderWorkThreads, requestRenderWorkThreads, null);

if(renderOnceList.size() > 0) clearRenderOnceList();

}


The actual runMonitor method is fairly complex, and it seems to perform the four functions shown in table 18.4, depending on the value of the first argument.


Table 18.4 runMonitor


Identifier

Index

Purpose


CHECK_FOR_WORK


0

Evaluates each thread and set the MasterControlThread to wait if none of the threads needs to be processed.

SET_WORK

1

Calls notify() on the MasterControlThread.


RUN_THREADS


2

Iterates through all the J3dThreadData under the control of the MasterControl. The notify() method is called on each thread associated with each J3dThreadData object.

SET_WORK_FOR_REQUEST_RENDERER

5

Sets the requestRenderWorkToDo member to true and calls



notify on the MasterControl thread.

The other arguments are (in order): the array of State Work Threads, the array of Render Work Threads, and the array of Request Render Work Threads. As you can see in the following pseudocode, Java 3D has the ability to call the doWork method on each worker thread directly. This enables Java 3D to perform the work of multiple threads within a single thread.


For all Render Work Threads

If the Thread needs to be run (J3dThreadData member),

Check whether the View should be rendered based on its Minimum Frame Cycle Time

Update the OrientatedShape3Ds in each View If specified lock the geometry from updates,

If the CPU limit is 1, call the doWork method of the J3dThreadData’s J3dThread directly

Otherwise call the runMonitor method (NOTIFY) to notify the thread If specified release the lock on the geometry,

If specified, grab the current time and put it into the View’s RenderBin

Next Rendering Thread

If specified, wait for all Rendering threads to complete For all State Work Threads

If the CPU limit is 1, call the doWork method of the J3dThreadData’s J3dThread directly

Otherwise call the runMonitor method (NOTIFY) to notify the thread Next State Thread

If specified, wait for all State threads to complete For all Request Render Work Threads

If the CPU limit is 1, call the doWork method of the J3dThreadData’s J3dThread directly

Otherwise call the runMonitor method (NOTIFY) to notify the thread Next State Thread

If specified, wait for all State threads to complete Update the View Frame Timing Values

Update all the Mirror Objects registered with the MasterControl Wait for Request Rendering to complete

Update the frame timestamps for each rendered View