[PD] why does PD round numbers? (in tables, in messageboxes, etc)

Tue Apr 10 19:38:45 CEST 2012

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.

.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 <jancsika at yahoo.com> wrote:
>>> ----- Original Message -----
>>> 
>>>> From: katja <katjavetter at gmail.com>
>>>> To: pd-list at 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 <zmoelnig at 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 at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>>> 
>>> 
> 
> 
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 
> 
> _______________________________________________
> Pd-list at 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