[PD] GUI overload

[Hans-Christoph Steiner]

It seems that there are a number of issues here:

* GUI objects sending every update, regardless of change (fixed)

* arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected

* all GUI activity stopping related to:
  return (sys_domicrosleep(0, 1) || sys_poll_togui())


* GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms.

* some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime

.hc

On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:

> OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
> 
> Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
> 
> Ed
>>  
> 
>> I tracked down the commit that seems to be causing the problem that Porres 
>> reported.  I think its a totally different problem related to Pd-0.43's new 
>> portaudio implementation.  It does not affect GNU/Linux, which doesn't use 
>> protaudio.  I haven't tested it on Windows.
>> 
>> https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55736&atid=478070
>> 
>> Ed, if part of your problem is arrays that stop updating and you're running 
>> on Mac OS X or maybe Windows, this might also be affecting you.
>> 
>> .hc
>> 
>> On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
>> 
>>> OK... except that I don't know why this works yet... by which i mean, I
>>> don't think it's possible that sys_domicrosleep(0 is returning 1s 
>> on every
>>> tick unless teh GUI itself is sending hundreds of messages per second down
>>> to Pd.
>>> 
>>> Reducing the average volume of trafic won't solve the underlying 
>> problem, it
>>> will just make it harder to recreate it :)
>>> 
>>> M
>>> 
>>> On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
>>>> 
>>>> I've seen similar things, like with the patches that Porres 
>> submitted.  It
>>>> looks like what's happening is that when there are too many updates 
>> being
>>>> sent, a lot of them get dropped.  Its pretty easy to get 250k per 
>> second of
>>>> Tcl code being sent to the GUI, so we're asking a lot of the Tcl 
>> parser and
>>>> compiler.  The solution is to reduce the amount of Tcl code that gets 
>> sent and
>>>> also use Tcl procs to handle bigger chunks of stuff so that we can take
>>>> advantage of Tcl caching parsed and compiled procs.
>>>> 
>>>> .hc
>>>> 
>>>> On 12/16/2012 01:47 PM, Miller Puckette wrote:
>>>>> This is just a guess... in s_inter.c, try replacing:
>>>>> 
>>>>> int sys_pollgui(void)
>>>>> {
>>>>>     return (sys_domicrosleep(0, 1) || sys_poll_togui());
>>>>> }
>>>>> 
>>>>> with:
>>>>> 
>>>>> int sys_pollgui(void)
>>>>> {
>>>>>     return (sys_domicrosleep(0, 1) + sys_poll_togui());
>>>>> }
>>>>> 
>>>>> It's possible that sys_domicrosleep(0 - which polls for input 
>> from GUI and
>>>>> other FDs - isn't ever returning "idle" (zero) so 
>> that sys_poll_togui() never
>>>>> gets called.
>>>>> 
>>>>> I've also seen a patch's GUI stop updating, but rather than 
>> bewail the fact 
>>>>> that my GUI was dead, my immediate reactions was to be astonished 
>> that the 
>>>>> sound was still working :)
>>>>> 
>>>>> Miller
>>>>> 
>>>>> On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
>>>>>> Hi List,
>>>>>> 
>>>>>> I'm not going to say whether this is a 
>> "recurrent" problem as it's hard to say whether the rewrite of the 
>> GUI has affected it...
>>>>>> 
>>>>>> I'm using a lot of abstractions with larger GOP or non-GOP 
>> GUIs, and I find the following problem occurs. There comes a point where the GUI 
>> objects stop responding in a patch when it is reloaded. I am wondering if there 
>> is a specific limit to GUI objects that could be changed. I think Pd is making 
>> some kind of decision that "there's too much of this stuff - I'm 
>> gonna prioritize the audio and not worry about it" and I'd like to know 
>> how or if it is possible to control this process from within Pd, or by setting 
>> flags on the command line.
>>>>>> 
>>>>>> I'm also making less GUI intensive versions for performance 
>> time, since the really big GUI patches are often pattern-sequencers which I will 
>> not want to program when I am performing. Example patch enclosed to give you an 
>> idea. The really GUI-intensive objects are the trackers, especially quadtracker 
>> (which I think has pushed the GUI of Pd patches about as far as I can go now).
>>>>>> 
>>>>>> System: quad core i5 PC running Ubuntu (10.04 Lucid), 
>> Pd-0.43-4, lots of externals compiled and loaded.
>>>>>> 
>>>>>> Warm wishes,
>>>>>> Ed
>>>>>> 
>>>>>> Gemnotes-0.2: Live music notation for Pure Data, now with 
>> dynamics!
>>>>>> http://sharktracks.co.uk/
>>>>> 
>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>>