[PD] GUI freeze
msp at ucsd.edu
Tue Sep 26 20:38:44 CEST 2017
I found at least one tcl-error bug and tried to fix it... can you try this
On Mon, Sep 25, 2017 at 05:35:55PM +0200, Roman Haefeli wrote:
> On Sam, 2017-09-23 at 08:45 -0400, Ivica Bukvic wrote:
> > This is likely dur to a buggy implementation of a particular widget
> > redrawing which may be a third-party widget.
> In my case I use only vanilla widgets, I but can't tell if it is caused
> by a single kind or rather by the number of them all combined.
> > It may be also due to out of sequence execution of commands in case
> > the widget does not enqueue all it's GUI commands like it should. One
> > way pd-l2ork 1.0 dresses this which is an ugly workaround but at
> > least it prevents you from losing GUI in the middle of a performance
> > is to process all TCL commands using the try/catch command (can't
> > remember the right syntax).
> > This way if a TCL command fails, the GUI will remain responsive. It
> > is possible this introduces an additional overhead in terms of CPU
> > usage even though I have not observed any.
> I very much would prefer this over what we have now. Not updating a
> bunch of events wouldn't be as bad as losing the whole stream like now.
> Maybe I make totally wrong assumptions, but I can't see how the fault
> can be on the widgets end since what suddenly fails is the path pd ->
> GUI, not the other way.
> BTW, neither of both processes, pd and wish, necessarily have a CPU
> load at 100% when this happens. So, what is the bottleneck here? I
> don't think it is the network connection to localhost.
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
More information about the Pd-list