[PD-dev] Fwd: [MACTCL] Improving Application GUI Speed
Hans-Christoph Steiner
hans at eds.org
Mon Apr 14 19:15:31 CEST 2008
On Apr 14, 2008, at 6:18 AM, Jakob Leben wrote:
> 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.
Sounds worth trying. pd.tk/u_main.tk is not very clean, that is well
known. You could start by trying to clean up some functions and
testing them out.
> 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.
Yeah, this should be done with 'move'. It is in some places but many
places, it is just deleting and redrawing. I think fixing that would
make a noticable difference and might not be too hard a place to start.
About shared memory, that sounds like a good idea. There are a lot
of possibilities. I think that Windows will be the hard one to
handle here. From this, it seems that mmap would be an easy way to
do it on Mac OS X and GNU/Linux. There could be two mmap'ed files
that serves as ringbuffers for communication between pd and pd-gui.
Here is a good page on the topic:
http://wiki.tcl.tk/1228
.hc
>
>
> 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
>
>
>
------------------------------------------------------------------------
----
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080414/fb1a6065/attachment.htm>
More information about the Pd-dev
mailing list