On Nov 1, 2007, at 1:06 PM, Martin Peach wrote:
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.
Even tho the screen updates at least evern 16ms, most GUI object do
not benefit from that at all. For example, number boxes would be
totally fine updating every 100ms or more, unless you like the look
of blurry numbers flying by. Sliders and buttons probably would be
fine at 50ms also
It would be nice to have this as part of the GUI API, so that it is
easy to use.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers