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 <[email protected]> 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 < > [email protected]> 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 < > [email protected]> wrote: > > i was Not clear i guess. I mean it never worked properly. A lot of > dropouts and lock ups. > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
