#1
|
|||
|
|||
quad buffered frame rate confusion
Hi, I'm running applications using quad buffered stereo, and I have the refresh rate set to 120 Hz. But when I run even the simplest Vizard script -
Code:
import viz viz.go(viz.QUAD_BUFFER) |
#2
|
|||
|
|||
Thanks for the post. Sorry, we have not had time to answer yet. We will respond tomorrow or early next week.
|
#3
|
|||
|
|||
Although I obviously hope you answer sooner, I just wanted to let you know that I really appreciate your acknowledgment of the question even when you don't have time to answer it.
|
#4
|
|||
|
|||
Are you sure your monitor actually supports a refresh rate of 120Hz? What monitor do you have? Vizards framerate is controlled by the vertical sync signal from the monitor, so it sounds like your monitor does not actually support 120Hz.
|
#5
|
|||
|
|||
Yes, for multiple reasons, I'm certain that the monitor (actually a projector) supports 120 Hz. The simplest reason is that viz.go() without viz.QUAD_BUFFER runs at 120 Hz.
I'm also sure that my video card - NVidia Quadro FX 3700 - supports quad-buffered stereo at 120 Hz, since I've tried it on a traditional analog monitor with a non-Vizard application. |
#6
|
|||
|
|||
Is the 120Hz projector the only device that's connected?
Is it s depthQ projector? if yes, then we have one sitting here at Worldviz for trouble-shooting. the only problem i have seen with the depthq is that it will NOT render stereo in 120 HZ if you have another device connected. so make sure that the ONLY device conneted to the graphics card is the projector. |
#7
|
|||
|
|||
I do have a second device (an standard analog monitor) connected to the video card, which has two independent DVI-I ports. After much exploration, it seems, however, that the video card bandwidth is narrower than I had expected. So turning down the resolution on the projector helped solved the problem, as did putting both devices at the same refresh rate (there must be some savings at the GPU).
So now viz.go(viz.QUAD_BUFFER) runs fine at 120 Hz. But I started to do some frame time logging with the following code: Code:
import viz import viztask def onFrameUpdate(event): global frameTime global frameInterval frameTime += [event.time] frameInterval += [event.elapsed] def collectFrames(): print 'Collecting frame times ...' viz.callback(viz.UPDATE_EVENT,onFrameUpdate) yield viztask.waitTime(60) print 'Finished collection.' viz.callback(viz.UPDATE_EVENT,None) yield writeFile() def writeFile(): file = open('frametime.txt','wt') file.write('frameTime = (') for i in frameTime: file.write(str(i)+',') file.write(')\n') file.write('frameInterval = (') for i in frameInterval: file.write(str(i)+',') file.write(')\n') yield file.flush() file.close() viz.quit() frameTime =[] frameInterval = [] viz.go(viz.QUAD_BUFFER) viztask.schedule(collectFrames()) |
#8
|
|||
|
|||
How precise do you expect the timing to be? When I log the elapsed time between frames it doesn't fluctuate more than 1ms from the expected rate. Either way, Windows does not run at real-time rates so your process can be interrupted by other processes at any time. You can tell Windows to give your process a real-time priority by using the following code:
Code:
import win32process import win32con win32process.SetPriorityClass(win32process.GetCurrentProcess(),win32con.REALTIME_PRIORITY_CLASS) |
#9
|
|||
|
|||
If the maximum deviation from the expected value were within 1 ms I would be happy. On my system it is not. At 120 Hz, the expected frame interval is around 8.333 ms. On one run, where the frame rate never noticeably dropped below 120 Hz, I get values in the range from 3.862 ms to 21.94 ms (see the attached histogram). Granted the variation is small; the standard deviation is 0.579 ms. (In the attached figure, counts above 20 are truncated.) However, the longer and shorter values, if accurate, suggest that frames are occasionally being dropped or skipped.
|
#10
|
|||
|
|||
Your code includes calls to disk every frame, right? You should try storing your timing info into an array and then after a set number of frames, write/flush to disk.
|
#11
|
|||
|
|||
No, the code doesn't write to disk on every frame, though it does do so after every trial - it is important to save experimental data after each trial in case of a crash, power-outage, or similar - which occurs irregularly, typically every 6 seconds (i.e., 6s x 120 Hz = 720 frames). But you're right, that does approximately account for the percent of frames that fluctuate significantly.
As another concern, I'm storing the frame timing in an array, which is appended on each frame. In Matlab - I have a lot of experience with Matlab - this would be very slow, and could be sped up by pre-allocating an array of the length I expect to use. Would this also speed up Python? |
#12
|
|||
|
|||
I don't know how efficient Python's array append call is, sorry. With Vizard, you generally don't have to worry about small performance issues such as that as long as all your frame processing can occur within 1/(frame rate) seconds.
Since you know matlab and seem intersted in performance related topics, you should read the Vizard docs under Reference / Python add-ons. There's a "just-in-time" compiler you can implement to speed up numerically heavy code, and there's also links to a project called "matplotlib" which provides matlab style plotting from Python. Also referenced is numpy (providing matlab like array & matrix notation), and PIL (imaging library like matlab's image toolbox). |
Thread Tools | |
Display Modes | Rate This Thread |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Linking problems with Live Character | Frank Verberne | Vizard | 5 | 06-04-2008 12:42 PM |
frame rate lock? | kgarr | Vizard | 1 | 02-23-2006 01:34 PM |
quad buffered stereo? | halley | Vizard | 2 | 10-19-2005 01:28 PM |