Re: [PD] Linux audio dropouts when moving mouse over patch (was: Pd hangs after installing Digidesign sound card's driver)
i was Not clear i guess. I mean it never worked properly. A lot of dropouts and lock ups.
i think it has something to do with tcl and the mouse
On Thu, Jun 19, 2014 at 5:55 PM, Simon Iten via Pd-list < pd-list@lists.iem.at> wrote:
i was Not clear i guess. I mean it never worked properly. A lot of dropouts and lock ups.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
tcl/tk is just doing what it's told, which is to send mouse movement notifications over the socket to Pd.
For each mouse motion message Pd receives from the GUI, it does a full loop over all the objects in the canvas to find out who was clicked. In edit mode, it can do up to two full loops if you did a "select all". (See canvas_findhitbox in g_editor.c). I'm assuming those are the most labor intensive parts of moving the mouse in Pd, but I haven't actually done any profiling.
Additionally, each iteration of the loop calls a getrectfn for the object being inspected. Typically that function just spits back the last values stored for the object's bbox. But if a single GUI external happens to do something oddly inefficient in that function, it is doing it every mouse motion message.
If these calculations + dsp graph calculation don't finish in the time it takes to compute a block, you'll get a dropout. And of course if you got a dropout, and you continue moving the mouse, you'll probably continue getting dropouts.
On the other hand, tk will put off redrawing the canvas until it has free time to do so. Thus redrawing may come regularly, sporadically, or in some unfortunate cases with Pd -rt, never. The fact that tk happily stops drawing at all when the core Pd process has realtime scheduling should tell you that tk is usually not the culprit in dropouts. It's unclear what the solution should be. If one removed all the widgetbehavior from "core" and put it in a separate "gui" process, then the patch author no longer has easy access to the visual diagram data. (Easy as in deterministic behavior when querying object positions or bboxes in a chain of objects that compute in zero logical time.) On the other hand, I think the GUI could just send a message telling Pd which object was actually clicked. (But keep all the getrect and hitbox functionality around so that if the user needs to fetch that data programmatically they can do so.)
-Jonathan
On Friday, June 27, 2014 5:50 AM, Billy Stiltner via Pd-list pd-list@lists.iem.at wrote:
i think it has something to do with tcl and the mouse
On Thu, Jun 19, 2014 at 5:55 PM, Simon Iten via Pd-list pd-list@lists.iem.at wrote:
i was Not clear i guess. I mean it never worked properly. A lot of dropouts and lock ups.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
as soon as a pointer moves within an object the object should be notified that the mouse is within it , no other objects should then be concerned nor be in any poll loop
On Fri, Jun 27, 2014 at 11:08 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
tcl/tk is just doing what it's told, which is to send mouse movement notifications over the socket to Pd.
For each mouse motion message Pd receives from the GUI, it does a full loop over all the objects in the canvas to find out who was clicked. In edit mode, it can do up to two full loops if you did a "select all". (See canvas_findhitbox in g_editor.c). I'm assuming those are the most labor intensive parts of moving the mouse in Pd, but I haven't actually done any profiling.
Additionally, each iteration of the loop calls a getrectfn for the object being inspected. Typically that function just spits back the last values stored for the object's bbox. But if a single GUI external happens to do something oddly inefficient in that function, it is doing it every mouse motion message.
If these calculations + dsp graph calculation don't finish in the time it takes to compute a block, you'll get a dropout. And of course if you got a dropout, and you continue moving the mouse, you'll probably continue getting dropouts.
On the other hand, tk will put off redrawing the canvas until it has free time to do so. Thus redrawing may come regularly, sporadically, or in some unfortunate cases with Pd -rt, never. The fact that tk happily stops drawing at all when the core Pd process has realtime scheduling should tell you that tk is usually not the culprit in dropouts.
It's unclear what the solution should be. If one removed all the widgetbehavior from "core" and put it in a separate "gui" process, then the patch author no longer has easy access to the visual diagram data. (Easy as in deterministic behavior when querying object positions or bboxes in a chain of objects that compute in zero logical time.) On the other hand, I think the GUI could just send a message telling Pd which object was actually clicked. (But keep all the getrect and hitbox functionality around so that if the user needs to fetch that data programmatically they can do so.)
-Jonathan
On Friday, June 27, 2014 5:50 AM, Billy Stiltner via Pd-list < pd-list@lists.iem.at> wrote:
i think it has something to do with tcl and the mouse
On Thu, Jun 19, 2014 at 5:55 PM, Simon Iten via Pd-list < pd-list@lists.iem.at> wrote:
i was Not clear i guess. I mean it never worked properly. A lot of dropouts and lock ups.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Billy Stiltner via Pd-list -
Jonathan Wilkes via Pd-list
-
Simon Iten via Pd-list