[PD] GUI and DSP

[Hans-Christoph Steiner]

On Feb 8, 2012, at 6:03 PM, Jonathan Wilkes wrote:

> ----- Original Message -----
> 
>> From: Ivica Ico Bukvic <ico at vt.edu>
>> To: Mathieu Bouchard <matju at artengine.ca>; Jonathan Wilkes <jancsika at yahoo.com>
>> Cc: "pd-list at iem.at List" <pd-list at iem.at>
>> Sent: Wednesday, February 8, 2012 3:33 PM
>> Subject: Re: [PD] GUI and DSP
>> 
>> 
>> 
>> Mathieu Bouchard <matju at artengine.ca> wrote:
>> 
>>> Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
>>> 
>>>> While technically correct that's misleading because there's a 
>> lot of 
>>>> stuff happening on the 'pd' side that a reasonable person would
>>> assume 
>>>> to be handled on the 'pd-gui' side.  Well, more than that-- 
>> there's 
>>>> stuff happening on the 'pd' side that doesn't need to 
>> happen at all,
>>> but 
>>>> it can use massive amounts of CPU and consequently a reasonable
>>> person 
>>>> gets dropouts when moving an array that has only 100 points visible
>>> and 
>>>> erroneously thinks, "Wow, I get dropouts just moving some polygons 
>> 
>>>> around on the screen? Tk stinks!"
>> 
>> Or you could simply use pd-l2ork and a move arrays and other complex graphical 
>> user interface objects using tags and never worry about that problem again.
> 
> But even in pd l2ork, if you have a million element array with 100 elements showing, 
> every time you click-drag a point in the array 'pd' recalculates the relationship between 
> points/elements for the _entire_ array, right?  At least that's what the code in g_array.c 
> looked like it was doing when I last looked at it.
> 
> If I understand it correctly, the 'pd-gui' waits for that c code to loop through the entire array before 
> it updates-- thus if you swoop the mouse through the entire array it may look like a 
> sluggish redrawing on Tk's part when actually it's redrawing just fine once it gets the 
> new coords, which takes time (and can cause dropouts).
> 
> That's a purposely exaggerated example, as it doesn't make a lot of sense to draw a 
> 100-point garray that represents a 1000000-element array.  But it makes me wonder 
> whether the "strobing" effect you get with a ds-array that has a lot of elements 
> happens because of similar heavy processing on the c side of things.
> 
> Has anyone tried to make a big polygon with lots of moving parts purely in tcl/tk and 
> measured the cpu?  Might help to see Tk's limits separated out from pd.

I just made a pure Tcl array like thing.  I made two versions, one using the create/delete technique that Pd uses, and another that uses the "coords" canvas command to update an existing line.  They both seem to use about 45% of my CPU on Mac OS X 10.6.8 running Tcl/Tk/Carbon 8.5.10.  Using Tcl/Tk/Cocoa 8.5.8 uses about the same, maybe a little less.  Since the Tcl/Tk canvas is on the main CPU, and not the GPU, its not going to be particularly fast at such things.

.hc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: coords.tcl
Type: application/octet-stream
Size: 681 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120210/4bcf1843/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: create-delete.tcl
Type: application/octet-stream
Size: 669 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120210/4bcf1843/attachment-0001.obj>
-------------- next part --------------



----------------------------------------------------------------------------

"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."        -John Gilmore