----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Mathieu Bouchard matju@artengine.ca; Jonathan Wilkes jancsika@yahoo.com 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.
-Jonathan
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g"
nor "%d"
when you can use "%x" and similar... especially fixed-width %x
such as
"%04x".
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net