[PD] how to capture window-related mouse-events when toxy is discontinued?

Jonathan Wilkes jancsika at yahoo.com
Fri Nov 4 18:37:53 CET 2011

----- Original Message -----

> From: Mathieu Bouchard <matju at artengine.ca>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: katja <katjavetter at gmail.com>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Friday, November 4, 2011 1:18 PM
> Subject: Re: [PD] how to capture window-related mouse-events when toxy is discontinued?
> Le 2011-11-04 à 07:37:00, Jonathan Wilkes a écrit :
>>  Functionally there is no difference between altering a polygon's shape 
> and the way I am moving it.
> In Tk, to change the coordinates of a canvas-item, you don't have to delete 
> it and recreate it. There's always a canvas-method named « coords » that 
> takes the same number of position arguments that the item-constructor did. So 
> for a rectangle-item, you give two points (four numbers) and for a N-gon 
> (N-sided polygon), you give N points (2*N points).
> It might not be much faster, though. I expect it to be only a tiny bit faster. 
> Just a bit less time parsing, about one less malloc and one less free (perhaps 
> several, because you have to remove a tag and add back the exact same). It 
> doesn't actually redraw anything between the delete and the create.

It seems like it does redraw stuff between the delete and create for a scalar with 
enough canvas items associated with it.  For example, if you make a ds array where each element is a 
little 10x10 rectangle and plot it with an array size greater than 100, you start to get a 
kind of strobing effect over the entire array when moving one element with the mouse.

> Now that I think of it, the bbox computation (necessary for scheduling the 
> redraw) is done twice using create/delete, only once using coords, but that 
> should be a small amount of time compared to parsing the command.
> BTW, extremely long strings of commands might be parsed repeatedly by the client 
> side in pd 43, because it's using [info complete] (just like desiredata). 
> But in practice, I didn't see it be a problem in profiling desiredata's 
> client's cpu usage, and I think pd 43 does it just the same.
> I didn't profile in all situations, though, so, the technique might hit 
> problems with big arrays, big DS, big moves or abuse of [print] or of other 
> post()/error().
> ______________________________________________________________________
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

More information about the Pd-list mailing list