On Fri, 12 Oct 2007, chris clepper wrote:
Note that every other frame pattern. Why is that? The low number is probably a fairly accurate number for the CPU to fetch the frame from disk, decode and then fling it up onto the GPU for texturing, but what about the other number? Add the two numbers together and they are almost exactly the time for two frames to render (about 33 ms at 60fps). The reason is that the driver will wait on the 'no load' frame for the next sync before returning which is why it runs too long.
Is it possible to make the frame-display call non-blocking ?Just like when you read from or write to a socket with O_NONBLOCK so that it returns immediately, or use SIGALRM to put a timeout on a read or write operation.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
