[PD] pd-gui update rate

Hans-Christoph Steiner hans at at.or.at
Fri Nov 18 20:42:01 CET 2011

One thing that would be very nice is if pd-gui checked the OS for the current screen refresh rate, and then used that as the clock for refreshing the GUI.  Seems quite feasible to me.  But actually, now that I think about it, I am sure that any decent GUI toolkit does this already, so really it seems that we should be offloading as much as possible to the GUI toolkit and have 'pd' itself speak on a higher level, e.g.:

  draw this object here, tell me if it was clicked"

versus the current:

draw these lines for the box, draw these lines for the inlets and outlets, draw this text, and check to see if the mouse is above this box or clicked on it so I can tell it to change its appearance


On Nov 18, 2011, at 12:41 PM, 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
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


Computer science is no more related to the computer than astronomy is related to the telescope.      -Edsger Dykstra

More information about the Pd-list mailing list