[PD-dev] Fwd: [MACTCL] Improving Application GUI Speed

Mon Apr 14 12:18:01 CEST 2008

So, I found out that garrays are drawn inside the function plot_vis in
g_template.c.

What I also found out is, that Tk drawing itself actually is already done
the way I described: there is at most as many Tk elements drawn as the
result of the relation between width of garray's graph and its X range. To
simplify: if you have a garray of 10000 data fields and both width and X
range of it's graph are set to 300 then the maximum amount of Tk elements
(be it line segments or rectangles) drawn will be 300.
This means that the Tk part of garray's visualisation is optimized.

Which in turn means that the slow part of drawing is acquiring data for
coordinates of Tk elements. Now here come my thoughts about that: as I see
functions in pd's code are heavily nested one inside the other. I mean, the
tendency seams to be towards a large amount of rather small functions that
call each other. I understand that code reusability is of value (this way
you can draw garrays with the same piece of code as all pd's data structures
created with the pd object 'struct'), but in the case of garrays where heaps
of data have to be processed/visualized it really slows the thing down. And
it's also hard to find out what piece of code is actually slowing things
down, when the program has to make hundreds of calls to perform one
intuitively simple task. I think in such a case there should be a dedicated
code optimized to work fast with large quantity of data.

Here I see two possibilities:
1. We could add some code to template.c that would treat garrays
differently. Though I'm not sure if one can know from inside the plot_vis
function whether a garray's data is being drawn or it is something else.
2. We could already on the level of garray redirect calls to functions that
result in plot_vis drawing garray's data to some dedicated drawing functions
for garrays.

If someone has thought on these proposals or any ideas, please comment.

One other "bug" I noticed that also slows things down but is of totally
different nature I suppose: every object that is drawn via 'graph on parent'
is being constantly deleted and recreated (in terms of Tk messages) when you
drag it's nesting subpatch around the parent patch. This results in the same
behaviour for garrays, because they are always drawn in the 'graph on
parent' manner.

J.

On Sun, Apr 13, 2008 at 6:55 PM, Hans-Christoph Steiner <hans at eds.org>
wrote:

>
> Hey,
>
> I am also quite interested in your code and the stuff you've written
> about, could provide links to both?
>
> About the array code, a good place to start is in pd/src/g_array.c.  Take
> a look there, and feel free to post any questions on this list so we can
> answer them.
>
> .hc
>
> On Apr 13, 2008, at 11:54 AM, Jakob Leben wrote:
>
> Hello to all the PD developers!
>
> As the word goes about improving pd's GUI speed, I thought this is the
> perfect opportunity for me to share some ideas, that I've already written
> about on the puredata.info homepage.
>
> Let me introduce myself first. My name is Jakob Leben, I'm from Slovenia
> and I'm actively using pure data. I can say I have quite some experience
> with writing pd externals, but I don't have an integral insight into pd's
> source code.
>
> Lately I made an external that visualizes pd's graphic arrays but much
> faster than pd natively does. (If I load 20 seconds of audio into a pd's
> array the drawing of the array causes clicks in audio. Another big problem
> is dragging a graphic array around the patch, that works extra slow.
>
> There are two things one could do:
> 1. change the algorithm for visualisation of array's data.
> 2. draw the data onto a specially loaded Tk canvas, so that when dragging
> the array around only the canvas' window is translated instead of all the
> coordinates for the line that represents data.
>
> Detailed explanation:
> 1. When the width of array's visualisation in pixels is smaller than the
> number of samples written into array it's useless to draw a segment of the
> line for each sample of data. Instead you can only draw one vertical segment
> of line for each column of pixels drawn: this segment's endpoints are
> defined by the minimum and the maximum value of the range of data that is
> "covered" by this pixel.
> The result of this is exactly the same as the way arrays are drawn now,
> though it involves much less line segments being drawn.
> 2. There is one problem that I came across with using a special canvas to
> visualise an array: a click on that canvas doesn't select the pd object that
> lies "under" this canvas. This canvas will always be "above" the object as
> all the objects are only items of one single Tk canvas, while this new
> canvas is the general canvas' child displayed as a general canvas' item of
> type window. Tk rule is that items of type window are always "above" all
> other items on a canvas.
> Thus it would be necessary to make a new binding for mouse events to this
> new canvas and somehow pass that click to pd's object.
>
> Now, I realized these ideas in the form of a pd extern that visualises an
> array, but i think it would be great to integrate those ideas into pd's
> arrays itself. I could do that if only I understood better how PD's arrays
> are drawn and how the selection of pd's object works... I tried but it seems
> to my like too big a project to dig out myself where in the code and how
> those things happen so I would appreciate very much if someone guided me
> through this.
>
> I'm willing to put all my effort into making those arrays draw faster.
>
> Sincerely,
> Jakob Leben
>
> On Sat, Apr 12, 2008 at 9:01 PM, Hans-Christoph Steiner <hans at eds.org>
> wrote:
>
> >
> > It seems there is a profiler for Tcl.  Has anyone ever tried it on Pd?
> >
> > Begin forwarded message:
> > > From: Revar Desmera <revarbat at gmail.com>
> > > Date: April 9, 2008 10:58:55 PM EDT
> > > To: TCL-Mac List <tcl-mac at lists.sourceforge.net>
> > > Subject: Re: [MACTCL] Improving Application GUI Speed
> > > Delivered-To: hans at eds.org
> > > X-Mailer: Apple Mail (2.919.2)
> > > X-Filter-Rule: ALL_LISTS
> > >
> > > If you download http://www.belfry.com/code/profile.tcl, and add a
> > > 'source profile.tcl' to the beginning of your program, when the
> > > program finishes, it'll dump a very detailed timing profile of your
> > > code to tclprof.txt, which you can use to determine what to optimize.
> > > The report format is very close to that of gprof.
> > >
> > >       - Revar
> > >
> > >
> > >
> > > On Apr 8, 2008, at 1:10 AM, Randolf Schultz wrote:
> > >> Hello,
> > >>
> > >> please help me getting my application up to speed on MacOSX/Aqua.
> > >> It runs fine on Linux/X11, Win32, and even MacOSX/X11. Only on
> > >> MacOSX/Aqua it crawls.
> > >>
> > >> Want to have a look first?
> > >> Go to
> > >>
> > >> http://sourceforge.net/project/platformdownload.php?
> > >> group_id=28460&sel_platform=4542
> > >>
> > >> (or http://www.ayam3d.org/download.html)
> > >>
> > >> get both variants (MacOSX/X11 and MacOSX/Aqua).
> > >>
> > >> Already the application startup is 2-3s (Linux/X11) vs. 10-15s
> > >> (MacOSX/Aqua); from then on the MacOSX version is unusably
> > >> slow, especially when drawing the scrollable GUIs for the object
> > >> properties (those are implemented as window in a canvas).
> > >> Another problem area are the pane widgets, that may be dragged
> > >> quite fine on X11, but on Aqua they do one hop every 1-2s (and
> > >> this is _without_ continuous re-packing the GUI, only dragging
> > >> the pane handle, which is a simple packed frame IIRC!).
> > >>
> > >> The Linux/X11 and MacOSX/Aqua variants were test-run on the
> > >> very same machine (MacMini-PPC)!
> > >>
> > >> So how would you proceed to tackle this problem?
> > >> Is there an easy way to profile such complex scenarios with Tcl/Tk?
> > >>
> > >> best regards,
> > >> Randolf
> > >>
> > >> ---------------------------------------------------------------------
> > >> ----
> > >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > >> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> > >> Monday, April 7! Use priority code J8TLD2.
> > >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://
> > >> java.sun.com/javaone
> > >> _______________________________________________
> > >> Tcl-mac mailing list
> > >> tcl-mac at lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> > >
> > >
> > > ----------------------------------------------------------------------
> > > ---
> > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > Don't miss this year's exciting event. There's still time to save
> > > $100.
> > > Use priority code J8TL2D2.
> > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://
> > > java.sun.com/javaone
> > > _______________________________________________
> > > Tcl-mac mailing list
> > > tcl-mac at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/tcl-mac
> >
> >
> >
> > ------------------------------------------------------------------------
> > ----
> >
> > Using ReBirth is like trying to play an 808 with a long stick.    -
> > David Zicarelli
> >
> >
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> >
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> Using ReBirth is like trying to play an 808 with a long stick.    -David
> Zicarelli
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080414/511f3c99/attachment.htm>