Text archives Help

---

I'm also surprised that you are seeing more than one frame of latency.

The current pipeline model wants to push the frames out as fast as it can. This is opposite of programs that are event driven. The reason for this was to prevent the high stop and start up times of threads "sleeping" and "waking up" whenever a new frame was requested. In addition the frames are drawn asynchronously from the UI removing the necessity of an event driven model.

What you want could be mimicked by doing a parallel animation callback. In this callback you can block all the threads with a semaphore until the UI signals it wants a frame drawn. This unblocks all the render threads draws a frame and then blocks on the callback again.

James

Abe Stephens wrote:

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.

If the transaction is added with the default flag during the rendering of frame i it will execute in the interval between frame i and frame i+1. After the transaction executes, frame i will be displayed with the old camera position. If the transaction is added to the queue during the interval that frame i is rendering but before the concurrent image display of frame i-1 completes, then two frames (i-1 and i) might be displayed before the first frame with the new camera state (i+1) is displayed. Of course if network latency is added to this time, more "old" frames would be displayed before the first new frame is displayed.

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


On Jul 31, 2007, at 11:58 PM, Christian Odom wrote:

Hey guys

I was wondering if someone could describe how the user interface works.

We wrote a camera that uses openGL matrices so that we could input the positional information from a tracking unit. We also wrote a Network UI to receive the tracking information and register a callback to set the matrix information in the Camera. Unfortunately, after a new camera position is sent to manta it takes several frames before the corresponding frame is displayed. This latency is undesired.

Would it be possible to have manta only render one frame when I give it a camera position and stop until I give it another update?

--
Christian Odom
Graduate Student
Center for Advanced Computer Studies
http://www.cacs.louisiana.edu
Louisiana Immersive Technologies Enterprise
http://www.lite3d.com

---

• [MANTA] UserInterface, Christian Odom, 08/01/2007
  • Re: [MANTA] UserInterface, Abe Stephens, 08/01/2007
    • Re: [MANTA] UserInterface, James Bigler, 08/01/2007

---

Archive powered by MHonArc 2.6.16.