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@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:
- change the algorithm for visualisation of array's data.
- 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:
- 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@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@gmail.com Date: April 9, 2008 10:58:55 PM EDT To: TCL-Mac List tcl-mac@lists.sourceforge.net Subject: Re: [MACTCL] Improving Application GUI Speed Delivered-To: hans@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.
- RevarOn 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@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@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@iem.at http://lists.puredata.info/listinfo/pd-dev
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli