[PD] GUI overload

[Ivica Ico Bukvic]

It makes things worse in pd-l2ork. Pd-l2ork did not need it (AFAICT) in the
first place since I had the netsend/receive fixed but I tried it anyhow just
to make sure and my conclusion is it makes things more sluggish gui-wise.

> -----Original Message-----
> From: pd-list-bounces at iem.at [mailto:pd-list-bounces at iem.at] On Behalf Of
> Hans-Christoph Steiner
> Sent: Thursday, February 14, 2013 10:07 PM
> To: pd-list at iem.at
> Subject: Re: [PD] GUI overload
> 
> 
> I don't quite understand.  Are you saying that this || to + change does
help
> or does not help?
> 
> .hc
> 
> On 02/14/2013 09:27 PM, Ivica Ico Bukvic wrote:
> > OK, so I had several L2Ork rehearsals on new machines with this patch
> > applied and I can confirm that this is actually a regression. GUI in
heavy
> > traffic situations gets visibly sluggish and falls behind, so to say.
This
> > still leaves the only notable difference between pd-l2ork and pd that
has so
> > far proven pd-l2ork resistant to the problems encountered below and
> those
> > have to do with the way how pd-l2ork has altered both
> netsend/netreceive and
> > also provided its own disis_netsend/receive externals that have been
> > reported before on this list to have fixed similar gui freeze issues...
> >
> >> -----Original Message-----
> >> From: Miller Puckette [mailto:msp at ucsd.edu]
> >> Sent: Thursday, December 20, 2012 11:46 PM
> >> To: Ivica Bukvic
> >> Cc: pd-list at iem.at
> >> Subject: Re: [PD] GUI overload
> >>
> >> My worry is, I'm not sure if there's still a problem out there that the
> >> || -. + change fixes.  Maybe I should try to cook up a formal
definition
> >> of what "working correctly" should consist of :)
> >>
> >> M
> >>
> >> On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote:
> >>> Miller,
> >>>
> >>> Pd-l2ork has this fix since your original post on the PD list and I've
> > yet
> >>> to see any regressions. Many thanks for the suggestion. That said,
I've
> > yet
> >>> to understand the logic behind it ;-).
> >>>
> >>> P.S. I also discovered quite a while ago that netreceive had a
tendency
> > to
> >>> freeze GUI permanently, likely due to asynchronous message
> processing. I
> >>> fixed this by enqueuing its messages and syncing them with the main PD
> >>> loop. This has been a part of pd-l2ork for over a year without a
single
> > GUI
> >>> freeze. That said, I did encounter situations where high traffic would
> >>> freeze GUI temporarily and then resume (albeit running now behind the
> >>> actual timeline as the GUI would simply resume as if nothing happened,
> >>> rather than processing all calls that have piled up since the
temporary
> >>> freeze happened and for which time has already passed, e.g. having a
> >> timer
> >>> in a score that freezes and then resumes from the moment it was stuck
> >>> rather than adding seconds lost since such calls should've been
> enqueued
> >>> while the freeze was in effect). This may have been in part due to
atom
> >>> cpus being taxed to their very limits. I've yet to see whether your
> >>> proposed fix resolves the lingering issue.
> >>>
> >>> HTH
> >>>
> >>> Best wishes,
> >>>
> >>> Ico
> >>> On Dec 20, 2012 7:02 PM, "Miller Puckette" <msp at ucsd.edu> wrote:
> >>>
> >>>> OK... I've pushed a change that seems to have fixed the
> >>>> arrays-atop-updating
> >>>> problem (at lest in the Brane example).  Not sure if I should also
> > commit
> >>>> the
> >>>>   return (sys_domicrosleep(0, 1) || sys_poll_togui())  ---> + change
> >>>> as well (somehow I think it should never be necessary to do that but
> > I'm
> >>>> realizing how little I understand Pd's scheduler.)
> >>>>
> >>>> cheers
> >>>> M
> >>>>
> >>>> On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner
> > wrote:
> >>>>>
> >>>>> 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=5573
> >> 6&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
> >>>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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