[PD] GUI and DSP

[Jonathan Wilkes]

----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Ivica Ico Bukvic <ico at vt.edu>; Mathieu Bouchard <matju at artengine.ca>; "pd-list at iem.at List" <pd-list at iem.at>
> Sent: Friday, February 10, 2012 10:48 PM
> Subject: Re: [PD] GUI and DSP
> 
> 
> 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.

Ah, nice!

For me the create-delete method uses more CPU but both are pretty intensive.

Any Qt devs out there?  Or gtk'ers?  Maybe a JUCEr?  Would those toolkits be able 
to utilize the GPU?  Those would be nice to compare, too.

-Jonathan

> 
> .hc
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> "[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
>