Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often than once per frame on the viewing device, but of course that signal (the vertical retrace or frame sync) is often hard to obtain. openGL sometimes has it builtin, does tk? 60Hz is 16.66...ms.
I'm not recommending to make it go at a rate above the monitor's rate. Usually, even a third of the monitor's rate is too much for Tk. I'm not 100% sure what is Tk's refresh rate, I think I've seen 50 ms (20 Hz). I don't think it ever checks the monitor's rate.
I thought you were suggesting to use the audio block size?... anyhow, surely not, as it's much above the frequency of the monitor.
I guess from pd's point of view the audio block determines the granularity of time, and messages are processed in between audio blocks, so it would be more difficult to synchronize drawing to another similar frequency. It seems like tk's drawing is opaque to the programmer in terms of exactly when it takes place, so then the network messages between pd and tk should be filtered at some multiple of the audio block that is similar to the screen rate. I mean for instance that only the last received command to a number box should be sent across the connection for each "display block". It may turn out that scanning the queue takes longer than just sending it all. Maybe it should be up to tk to filter the extra commands. Maybe it already does.
Martin