[PD] pd-gui update rate

[Roman Haefeli]

Hi

Thanks to Charles, Matju and Miller for your answers. 

It's somewhat clearer now how those things are working together. In the
meanwhile, I made some test. I figured I'd probably be able to determine
the refresh rate myself with the help of the nyquist theorem. I made a
patch that lets the background color of an iemgui flicker between black
and white at a settable rate. Assuming that when I hit twice the Nyquist
frequency of the refresh rate (which equals the refresh rate) the
visible flicker frequency should go towards zero, which means the slider
should stay black or white. Apparently, this happens when I set the
[metro] to 8.33333 ms.  The actual period is twice that, because I need
a metro tick for the white and one for the black phase. So the whole
period amounts to 16.6666ms which corresponds to 60 Hz, which is the
refresh rate of my screen. 

Somehow I was always assuming that Tk (at least in Pd) is rendering
slower than that. Don't know why I believed in that myth. Actually, I
like being able to use the full speed of my screen in Pd. Yet, in many
patches I often artificially limited GUI refreshs to 20 Hz, assuming
that higher rates wouldn't be displayed anyway. Wrong!

Thanks!
Roman

 
On Fri, 2011-11-18 at 09:41 -0800, Miller Puckette wrote:
> There's no fixed update rate, but Mahieu is right, Pd polls for the
> ability to make an update every DSP tick.  (one is able to do an update
> if the socket from Pd to GUI is writable, i.e., not full).
> 
> I've thought for a long time about putting an explicit throttle (on the order
> of 5-10 msec) or a flow control mechanism (passing round-trip tokens through
> the GUI to see when things are actually getting updated) but have put this
> off because of more urgent problems :)
> 
> M
> 
> On Fri, Nov 18, 2011 at 11:48:25AM -0500, Mathieu Bouchard wrote:
> > Le 2011-11-18 à 09:34:00, Roman Haefeli a écrit :
> > 
> > >Ah.. I was actually looking for the number 14112000, but of course
> > >I didn't look for 32. * 441000. But then, 14112000 / 5000 gives
> > >2822.4 Hz, which would be a too high rate for GUI refresh. So,
> > >what is relation between the tick and 5000 that leads to a sane
> > >GUI refresh rate (and finally, what _is_ the GUI refresh rate)?
> > 
> > Oops !
> > 
> > sched_tick handles the span of time of one hardware dsp block, and I
> > think that this is usually frozen to be 64 samples regardless of
> > sampling rate (for 44100 Hz, this is 1.45 ms). the while() loop
> > looks for all upcoming
> > clock events ([metro], [delay], [pipe], etc) and processes them
> > until the time of the next dsp block.
> > 
> > The 5000 might be never used. You'd need 5000 [metro] or [delay]
> > objects being activated between two consecutive dsp blocks. In
> > addition to being very unlikely, it's also nearly impossible to do :
> > if 5000 objects put 5000 things in the clock queue in chronological
> > order, this takes 12.5 million loops per clock tick, and each loop
> > is 3 comparisons and 2 assignments. No CPU has the time to do it in
> > one tick. Pd doesn't have to be like that, there are good
> > datastructures that it could use, but it does not use them, so it's
> > extremely inefficient at some things when those things appear in
> > large numbers.
> > 
> > You can get well over 5000 clock activations in one dsp tick, but
> > you have to do it in other ways. you need a self-connected [delay]
> > with an extremely low number, because [metro] won't let you make a
> > [metro] that fast.
> > 
> > Anyway, I don't get it, I mean I don't get the existence of the
> > 5000. My previous answer about 14112000 was a mistake : the number
> > is correct but unrelated.
> > 
> > Instead, sys_pollgui is called almost only from m_pollingscheduler...
> > 
> > It looks like it's called at every dsp tick (1.45 ms) but inside
> > sys_pollgui it calls sys_domicrosleep which is actually a function
> > that checks all filehandles for incoming data, and if there's no
> > incoming data in a given tick, then sys_poll_togui is called. That
> > one, in turn, checks whether the output buffer is empty, and if it
> > isn't, then it doesn't call sys_flushqueue.
> > 
> > So, the answer seems like it's that pd refreshes the gui using a
> > clock of 689 Hz, and the fastest possible GUI updates would be half
> > of that, but Tcl never keeps up with that, so it slows down the rate
> > by just not reading enough stuff that pd sends it, and pd skips
> > calls to sys_flushqueue in those cases.
> > 
> >  ______________________________________________________________________
> > | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
> 
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>