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
.hc
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@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