[PD] how to capture window-related mouse-events when toxy is discontinued?
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
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
More information about the Pd-list