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