Found the culprit in: g_template.c
in function
plot_vis: /* We're done with the outline; now draw all the points. This code is inefficient since the template has to be searched for drawing instructions for every last point. */
However, there are really two problems here:
- Sluggishness when moving a "Put" menu array with the mouse in editmode. Pd should really just move those
rectangle items that are already plotted-- plot_vis doesn't need to be called if the user is in the act of displacing the
graph.
Does pd-l2ork do that?
- Sluggishness when creating an array, or opening a subpatch with one inside, or plotting a signal using
[tabwrite~], or populating an array using [soundfile]. Making the code inside plot_vis more efficient would indeed
improve all of these issues, though I'm not sure how to do that.
-Jonathan
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Patrice Colet colet.patrice@free.fr; pd-list pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Cc: András Murányi muranyia@gmail.com Sent: Saturday, August 27, 2011 5:44 AM Subject: Re: [PD] [PD-dev] tkwidgets
Btw-- even for the size 1000 array above, part of the cpu usage and
sluggishness is
caused by whatever computations pd is doing before sending the message to
the
gui to create the next rectangle (see my message earlier in this thread).
So my
example isn't exactly comparing tcl/tk speed to pd computation speed--
it's more like
comparing a slightly bad apple to a much worse apple. In both cases I
think the
significant "sluggishness" digits are due to whatever pd is doing
between message
sends.
while no one has time to work on the real problem behind (described by Jonathan), I would suggest a hack solution: instead of a copy of an image (as suggested by someone), just turn the display off while the selection is moving? doesnt' solve the real issue, but avoids some dropouts/slugishness.