----- Original Message ----- > From: Hans-Christoph Steiner <h...@at.or.at> > To: Miller Puckette <m...@ucsd.edu> > Cc: pd-list@iem.at > Sent: Tuesday, April 10, 2012 1:38 PM > Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc) > > > Makes sense to me. Each individual point can have its own coords, fill, > color, > tags, etc. while a polygon just has one set of all those for the whole thing. > > This whole discussion makes me think that arrays should be available to the > GUI > via shared memory. Then the 'pd' side can freely update things on its > own clock, while 'pd-gui' can update things using its own clock (much > slower, like 60hz) and also its own resolution. For example, if a 400 > million > point array is drawn in a 400 pixel wide box, then the GUI can just read > every > 100,000th value in the array. > Or for more accuracy, take the median of those > 100,000 points, or mean for perhaps more accuracy. That should drastically > speed up array drawing.
How do you calculate the median/mean without iterating through the array? -Jonathan > > .hc > > On Apr 10, 2012, at 1:31 PM, Miller Puckette wrote: > >> Hi all - >> >> It's a wierd thing abut TK that drawing polygons is far more efficient >> than drawing arrays of points; "polygons" are primitive objects > that >> are apparently optimized internally to TK whereas arrays of points have >> to be drawn one by one (TK thinks they're each a separate object). >> >> cheers >> Miller >> >> On Tue, Apr 10, 2012 at 07:24:31PM +0200, katja wrote: >>> Thanks for your tips, Jonathan. Anyway, while you were writing the >>> mail I was already doing a test patch where update times of a 32 >>> million samples array and table are tested, see attached. >>> >>> I ran the test with Pd-extended 0.43.1 and Pd-double on OSX. For an >>> array with that length, update takes ~3 seconds. For a table displayed >>> graphically, ~3.1 seconds. Surprisingly, drawing as points (instead of >>> polygon) takes almost 5 seconds. The deviation between repeated >>> measurements, a few dozen milliseconds, was about as large as the >>> difference between Pd-extended and Pd-double. I've verified that >>> double precision numbers are indeed displayed with a maximum of 14 >>> significant digits in Pd-double. >>> >>> I also checked the time for writing 32 million samples to a table >>> without graphical display. This took ~170 milliseconds for Pd-extended >>> and ~ 220 milliseconds for Pd-double. >>> >>> Later I'll do another test where transmission over network is more >>> specifically tested. >>> >>> Katja >>> >>> >>> >>> On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes > <jancs...@yahoo.com> wrote: >>>> ----- Original Message ----- >>>> >>>>> From: katja <katjavet...@gmail.com> >>>>> To: pd-list@iem.at >>>>> Cc: >>>>> Sent: Tuesday, April 10, 2012 9:45 AM >>>>> Subject: Re: [PD] why does PD round numbers? (in tables, in > messageboxes, etc) >>>>> >>>>> 2012/4/10 IOhannes m zmölnig <zmoel...@iem.at>: >>>>>> On 04/10/12 10:33, katja wrote: >>>>> >>>>>> i was talking about pd/pd-gui communication (and keep the > number format for >>>>>> both saving and pd/gui communication the same). >>>>>> when displaying/updating a table every single number is > converted to text >>>>>> using printf, send over the wire and then converted back > to a number for >>>>>> drawing the table. >>>>>> it makes a difference if you have to transmit 44100 >>>>>> *4 bytes or 44100*12 bytes. >>>>> >>>>> Ah I see. It is not uncommon to display complete audio files, > much >>>>> more than 44100 samples. >>>> >>>> I've never seen a patch that _displays_ all the data for an > array that large. To >>>> >>>> transmit 44,100 drawing instructions you need a _canvas_ size of > "44100" and >>>> >>>> if anyone has actually needed to do that in a patch I'd really > like to see it. >>>> >>>> >>>>> So all these samples are converted to text >>>>> and back to numbers, as they go over the network? >>>> >>>> No. See plot_vis inside g_template.c. There is not a 1-to-1 > correspondence between >>>> # of array elements and rectangles/polygon-coords on the tk canvas > (at least for >>>> garrays, not sure about data structures). If you create a 44100 > element array >>>> and make the "size" field in that arrays canvas dialog > "2", Pd will only send >>>> data to the gui for those 2 pixels, not for the entire array. > However, it will loop >>>> through the entire array on the c side _every_ time plot_vis is > called, in order to >>>> figure out what info should be sent to the gui. >>>> >>>> For example: running with -d 3, create an array with 10,000,000 > elements. >>>> Now make the "size" field in its canvas dialog > "2". >>>> Select the array. >>>> Click an array key to move it. >>>> Notice the lag, but also notice Pd is only sending two commands to > the gui to >>>> draw the elements. >>>> It's because Pd must loop through 5,000,000 elements before it > hits the next pixel >>>> where it needs to send another drawing instruction to the gui! >>>> >>>>> (While in the end, >>>>> only a couple hundred values are displayed). And every > character goes >>>>> through the loop in binbuf_text() with all it's cases... > well that is >>>>> a bottleneck which should not be further aggravated. >>>>> At least this >>>>> performance issue can be quickly tested, using Pd vs Pd-double. > I'll >>>>> make a test patch for that. >>>> >>>> Keep in mind that you're using a horribly implemented feature > of Pd to do your >>>> test-- that is, if you're using garrays. For example, moving > an array shouldn't >>>> >>>> send _any_ element data to the gui. It doesn't in Pd-l2ork > because it just moves >>>> >>>> everything by tag, using one line of tk, thus there is no > bottleneck in that case. >>>> >>>> A practical test I can think of to compare 4byte vs 12byte payload > is >>>> >>>> something like [metro 100]--[tabwrite~] animation for a visible > garray. I'd be >>>> >>>> curious to know if there is a significant performance difference > there. >>>> >>>> >>>> -Jonathan >>>> >>>> >>>>> >>>>> Katja >>>>> >>>>> _______________________________________________ >>>>> Pd-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>>> >>>> >> >> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > ---------------------------------------------------------------------------- > > Looking at things from a more basic level, you can come up with a more direct > solution... It may sound small in theory, but it in practice, it can change > entire economies. - Amy Smith > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list