Concurrent Actors has smooth animation, but it isn't slowed by excessive refreshing. Because frame rate is often limited by hardware refresh rates--such as in standard video displays (60 frames per second)--performing image refresh more often than hardware refresh just wastes time. Besides, lower frame rates can yield smoother animation.
Refresh is accomplished in two phases: setup and execution. The setup phase allows an object to adjust its appearance according to the time that has elapsed since its last refresh. The execution phase actually draws the object. For details on the execution phase, see "Refreshing the screen" (page 43).
The refresh thread doesn't apply back-to-front ordering of refreshing objects. Because important objects can't overlap in this simulation such ordering
In a simulation that needs back-to-front ordering, it's possible to derive a new class from TRefreshThread and add the behavior. An easier solution might be to implement ordered planes as refreshing objects containing other refreshing objects in the same plane.
Refreshing objects are owned by the Universe subsystem which coordinates the many activities a refreshing object might be involved in (such as moving
Two-phase refresh
Avoiding deadlocks
in the refresh thread
The Refresh subsystem has the same concurrency concerns the Movement subsystem has and it solves them in the same way. Control flows only from refresh thread to refreshing object, never the other way around. No back-to-front
ordering necessary
is unnecessary. The refresh thread
doesn't own
refreshing objects
and colliding).
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Generated with WebMaker