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. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
