Hi, 

I'm a bit surprised that the latency between adding a camera transaction and seeing the effect would be noticeable if the renderer was running at sufficient rates.

Since rendering and display are pipelined there's a one frame latency between rendering and display which is unavoidable. This design allows the renderer to scale without a serial image display bottleneck. Transactions do not "interrupt" frames when added to the queue, instead the transactions aren't processed until all of the threads finish rendering the current frame.

Each transaction may change how the rest of the transaction queue is processed. By default all transactions in the queue are executed each frame: if camera updates are arriving faster than the frame rate, the very last one to arrive will be executed before the frame is rendered. TransactionBase.h defines two other flags: Continue causes the transaction to execute and then skips to rendering the frame. This is useful to obtain a one-to-one relationship between camera updates and rendered frames. If camera updates arrive faster than the frame rate it will take several frames to catch up to the head of the queue. The Purge flag causes the transaction to execute and then removes any remaining transactions from the queue. Useful if the transaction performs some action which might invalidate subsequent transactions from asynchronous sources.

For most applications this maximum of 2 frame latency isn't a problem, camera transitions are very small and the frame rate is sufficiently high that the latency isn't noticeable. If displaying old frames is an issue in your application you might try writing a wrapper ImageDisplay class which could ignore frames with old camera information. In your camera transaction update the camera state as usual and then specify a minimum frame number for the image display to continuing rendering at. The frame number of the currently rendering frame is given by mantainterface->getCurrentFrame().

Currently there isn't a tested mechanism within the pipeline in RTRT.cc to discontinue rendering after image display or to stop and starting rendering threads without exiting the main rendering loop. I think there's room within the interfaces to implement such a system, but it's probably easier to try discarding frames with old rendered data first.

 

Abe