[PD] GUI overload

Ivica Ico Bukvic ico at vt.edu
Fri Feb 15 03:27:56 CET 2013


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





More information about the Pd-list mailing list