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

[Miller Puckette]

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