[PD] pd-gui update rate

[Mathieu Bouchard]

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