hello,

i would be very happy to have an external for a fast array drawing. i don't know what miller think about that, but having this inside pd would be perfect!

where can we get the source of this external?

Thanks for solving this kind of pd problem.

Cyrille

Jakob Leben a écrit :

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 http://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@eds.org mailto: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 <mailto:revarbat@gmail.com>>
 > Date: April 9, 2008 10:58:55 PM EDT
 > To: TCL-Mac List <tcl-mac@lists.sourceforge.net
<mailto:tcl-mac@lists.sourceforge.net>>
 > Subject: Re: [MACTCL] Improving Application GUI Speed
 > Delivered-To: hans@eds.org <mailto: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.
 >
 >       - 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 <http://java.sun.com/javaone>
 >> _______________________________________________
 >> Tcl-mac mailing list
 >> tcl-mac@lists.sourceforge.net <mailto: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 <http://java.sun.com/javaone>
 > _______________________________________________
 > Tcl-mac mailing list
 > tcl-mac@lists.sourceforge.net <mailto: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 <mailto:PD-dev@iem.at>
http://lists.puredata.info/listinfo/pd-dev

---

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

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:

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@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.

  - 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@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

On Apr 14, 2008, at 6:28 AM, IOhannes m zmoelnig wrote:

Jakob Leben wrote:

...

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

not directly, but: does anybody know how one could setup a shared- memory between pd and pd-gui? i think it would be a good idea to not send large amounts of data through a network socket. (i had a look at [pix_preview] the other day, and noticed that it is not really usable with larger image-data; shared-memory might be a solution for this as well...)

fmgasdr IOhannes

For pix_preview, I was thinking, it could allocate two framebuffers and one lock variable. In the lock variable would be the address of the framebuffer that is currently ready for Tcl to draw. On the C side, it would be filling the other framebuffer in the meantime. Once that is all done, it would change the lock variable to point to the new one. This could be done with mmap and the lock variable would just be a filename, and the Tcl image object would just read the mmap'ed file for the image data.

Just throwing it out there.

.hc

------------------------------------------------------------------------ ----

There is no way to peace, peace is the way. -A.J. Muste

Sounds interesting, you can post the code here in the email. If it is a patch against Pd, then you can submit it to the patch tracker:

http://puredata.info/dev/patchtracker

From how you described this, I think there might be a better way to implement this. Adding another function to widgetbehavior means that in order to take advantage of this fix, every single GUI object will have to be changed to use that new function.

Perhaps there is a way of implementing this in the displace_fn? IIRC, the displace_fn is meant for moving already, so no need to define a new move function.

Thanks for taking this on, it is a very valuable contribution!

.hc

On Apr 15, 2008, at 1:04 AM, Jakob Leben wrote:

OK, I think I did it. Solved the slow garray drawing.

I introduced a new widgetbehavior of the same form as t_displacefn. All children of a graph get their new widgetbehavior called from graph_displace. That's way I called the new widgetbehavior t_graphfn, maybe we could find something better to make clear the following notion: each object should write into it's graphfn function only procedures to move it's graphical content with calls to Tk command "move"; t_graphfn function provides in form of it's arguments dx and dy to use with Tk move just as t_displacefn does (graph_display passes it's dx and dy arguments on to every t_graphfn call it makes).

I've filled in graphfn functions for everything connected with data structures and arrays, it remains to write those functions for iemgui and oldschool "text" objects. Coming soon. And for somebody who wants to write new graphical externals the change will be almost invisible, because we can make an iemgui_graph function to map to t_graphfn, that will call x_gui.x_draw with IEM_GUI_DRAW_MODE_MOVE, so one really doesn't need to write any more GUI code than before.

Performance is greatly improved, I can load 20secs of audio into an array and it moves around a patch smoothly, though it demands it's 40-50% cpu. But anyway, it works. I also tweaked some other pieces of code to remove unnecessary multiple calls to garray_vis. I haven't yet tried if it disturbs heavy audio processing when you load a large sample into an array. That's my main concern with arrays to be honest.

So, what's the regime for spreading this code of mine into the wide world? do you want to check it out? Shall I simply attach it to an email? Can I upload the code somewhere?

J.

On Mon, Apr 14, 2008 at 7:19 PM, Hans-Christoph Steiner hans@eds.org wrote:

On Apr 14, 2008, at 6:28 AM, IOhannes m zmoelnig wrote: Jakob Leben wrote:

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

not directly, but: does anybody know how one could setup a shared- memory between pd and pd-gui? i think it would be a good idea to not send large amounts of data through a network socket. (i had a look at [pix_preview] the other day, and noticed that it is not really usable with larger image-data; shared-memory might be a solution for this as well...)

fmgasdr IOhannes

For pix_preview, I was thinking, it could allocate two framebuffers and one lock variable. In the lock variable would be the address of the framebuffer that is currently ready for Tcl to draw. On the C side, it would be filling the other framebuffer in the meantime. Once that is all done, it would change the lock variable to point to the new one. This could be done with mmap and the lock variable would just be a filename, and the Tcl image object would just read the mmap'ed file for the image data.

Just throwing it out there.

.hc

---

---

There is no way to peace, peace is the way. -A.J. Muste

------------------------------------------------------------------------ ----

Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra

hello,

this patch is great. i hope miller will accept it!

thanks

Cyrille

Jakob Leben a écrit :

I will think of doing it the displace_fn way. Though my first thoughts are sort of equally sceptic as your critique of including new widgetbehavior:

Displacefn functions usually either create or delete graphics, so to "displace" the graphics you usually call it twice: first with vis = 0 to erase the graphics and then again with vis = 1 to recreate the graphics. Now, to implement new style of moving graphics we could call the displace_fn with a new value for it's vis argument which would require displace_fn to act accoringly to this flag. But displace_fn functions usually only check if "vis" = true or false, so all the objects that wouldn't have a dedicated interpretation of our new vis value would either erase their graphics and never draw it again, or create it again without the old being erased. Which means again that for the system to function properly all the GUI objects should have their displace_fn functions modified.

From this perspective it looks to me better to make a dedicated widgetbehavior. This way when compiling some code that wouldn't have this widgetbehavior initialized you at least get a warning from compiler, or on the other hand pd crashes when calling the uninitialized widgetbehavior and you know for sure that something is wrong.

Plus, do you think there's a large amount of GUI externals? I think a big many of externals only have basic "t_text" graphical represantion. And I have already written displace_fn functions for all the pd vanilla GUI classes.

I've uploaded the patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1943301&gro... http://sourceforge.net/tracker/index.php?func=detail&aid=1943301&group_id=55736&atid=478072

J.

On Tue, Apr 15, 2008 at 7:11 PM, Hans-Christoph Steiner <hans@eds.org mailto:hans@eds.org> wrote:

Sounds interesting, you can post the code here in the email.  If it
is a patch against Pd, then you can submit it to the patch tracker:

http://puredata.info/dev/patchtracker

 From how you described this, I think there might be a better way to
implement this.  Adding another function to widgetbehavior means
that in order to take advantage of this fix, every single GUI object
will have to be changed to use that new function. 

Perhaps there is a way of implementing this in the displace_fn?
 IIRC, the displace_fn is meant for moving already, so no need to
define a new move function.

Thanks for taking this on, it is a very valuable contribution!

.hc


On Apr 15, 2008, at 1:04 AM, Jakob Leben wrote:

...

OK, I think I did it. Solved the slow garray drawing.

I introduced a new widgetbehavior of the same form as
t_displacefn. All children of a graph get their new widgetbehavior
called from graph_displace. That's way I called the new
widgetbehavior t_graphfn, maybe we could find something better to
make clear the following notion: each object should write into
it's graphfn function only procedures to move it's graphical
content with calls to Tk command "move"; t_graphfn function
provides in form of it's arguments dx and dy to use with Tk move
just as t_displacefn does (graph_display passes it's dx and dy
arguments on to every t_graphfn call it makes).

I've filled in graphfn functions for everything connected with
data structures and arrays, it remains to write those functions
for iemgui and oldschool "text" objects. Coming soon. And for
somebody who wants to write new graphical externals the change
will be almost invisible, because we can make an iemgui_graph
function to map to t_graphfn, that will call x_gui.x_draw with
IEM_GUI_DRAW_MODE_MOVE, so one really doesn't need to write any
more GUI code than before.

Performance is greatly improved, I can load 20secs of audio into
an array and it moves around a patch smoothly, though it demands
it's 40-50% cpu. But anyway, it works. I also tweaked some other
pieces of code to remove unnecessary multiple calls to garray_vis.
I haven't yet tried if it disturbs heavy audio processing when you
load a large sample into an array. That's my main concern with
arrays to be honest.

So, what's the regime for spreading this code of mine into the
wide world? do you want to check it out? Shall I simply attach it
to an email? Can I upload the code somewhere?

J.

On Mon, Apr 14, 2008 at 7:19 PM, Hans-Christoph Steiner
<hans@eds.org <mailto:hans@eds.org>> wrote:


    On Apr 14, 2008, at 6:28 AM, IOhannes m zmoelnig wrote:

        Jakob Leben wrote:


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


        not directly, but: does anybody know how one could setup a
        shared-memory
        between pd and pd-gui?
        i think it would be a good idea to not send large amounts
        of data
        through a network socket.
        (i had a look at [pix_preview] the other day, and noticed
        that it is not
        really usable with larger image-data; shared-memory might
        be a solution
        for this as well...)

        fmgasdr
        IOhannes


    For pix_preview, I was thinking, it could allocate two
    framebuffers and one lock variable.  In the lock variable
    would be the address of the framebuffer that is currently
    ready for Tcl to draw.  On the C side, it would be filling the
    other framebuffer in the meantime.  Once that is all done, it
    would change the lock variable to point to the new one.  This
    could be done with mmap and the lock variable would just be a
    filename, and the Tcl image object would just read the mmap'ed
    file for the image data.

    Just throwing it out there.

    .hc

    ----------------------------------------------------------------------------

    There is no way to peace, peace is the way.       -A.J. Muste

----------------------------------------------------------------------------

Computer science is no more related to the computer than astronomy
is related to the telescope.      -Edsger Dykstra

---

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

On Tue, 15 Apr 2008, Hans-Christoph Steiner wrote:

From how you described this, I think there might be a better way to implement this. Adding another function to widgetbehavior means that in order to take advantage of this fix, every single GUI object will have to be changed to use that new function.

You need a new version of class_setwidgetbehavior if you want any binary compatibility. it has to be named differently. This is required to distinguish structs that have 7 functions from structs that have 8 functions.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

To start with, I think you should get a nice tight patch for switching garrays to using 'move' so we can see if this is really worth pursuing and what problems in might cause.

Please keep on experimenting with all things. But just so you know, if you want to get these patches included into pd-vanilla or pd- extended, they either need to be small or really well tested. So completely reworking garrays is probably something better attempting after we know that this core idea works out well (using move instead of delete/create).

.hc

On Apr 21, 2008, at 12:18 AM, Jakob Leben wrote:

Well, I've kinda given up on using a new widget behavior. However, as you can see on the patch tracker, I managed to make garrays use Tk command move instead of redraw their data by only changing the graph_displace function and adding a couple of other functions to g_array.c, g_scalar.c and g_canvas.h. So this way all other classes are untouched while only improving garray, which was the most critical.

Currently I am dealing with the plotting of garray's data itself, because this seems too CPU expensive in the first place. Here the only solution I see is to plot it out piece by piece if the number of elements goes over a limit so as to give the computer time for audio computation in between. I have no other idea how to constrain the plotting function to not take too much of CPU power at the instant it tries to draw all the elements.

Any suggestions?

Well, yeah, actually I did come up with one rather radical idea: Absurdity of current implementation: garrays now take so much care to constrain the functionality of the pd data structure system they use to save & draw their data (graph, scalar, array, plot classes...) by which I mean: for example they try to avoid the settings for graphing on parent (X range, Y range) by fitting their graph to their liking whenever they are redrawn; another thing is that they use their dedicate preformed data template while basically we have templates here to do all kinds of structures with them...

...well, considering all this together with the fact that the most CPU intensive part of drawing of garrays is transforming the data they contain into pixel coordinates telling (stretching according to graph on parent settings that they set themselves to fit their data into the bounding rectangle of their graph) - it comes to me naturally to ask myself: why do we use those data structure classes for functionality of garray? If garrays are in the first place meant to be filled with audio data which usually involves thousands of elements, we could really write some special code to handle how this data is written into them and how it is displayed on the screen.

It might seem extremely daring or even bold but I would propose a complete reworking of the garray class. And I think it really shouldn't be so much work after all, because things are now extremely overcomplicated while we could implement the same functionality with a code less interwoven with general data structure classes, but a lot simpler and more effective one.

Sincerely, J.

On Mon, Apr 21, 2008 at 5:20 AM, Mathieu Bouchard matju@artengine.ca wrote: On Tue, 15 Apr 2008, Hans-Christoph Steiner wrote:

...

From how you described this, I think there might be a better way

to implement this. Adding another function to widgetbehavior means that in order to take advantage of this fix, every single GUI object will have to be changed to use that new function.

You need a new version of class_setwidgetbehavior if you want any binary compatibility. it has to be named differently. This is required to distinguish structs that have 7 functions from structs that have 8 functions.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

------------------------------------------------------------------------ ----

All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne

In the future, keep on posting to the same patch number in the patch tracker, rather then opening new patches for each chance. It makes it much easier to follow that way. I closed the duplicates.

I'll take a look when I can. But first I want to get the 0.40 release out ASAP, then we can all focus on making 0.41 better.

.hc

On Apr 21, 2008, at 2:24 PM, Jakob Leben wrote:

OK, I submitted a tight little patch to patch tracker containing only as few changes as necessary.

I suggest that admin deletes the patches I submitted before with request IDs 1943614 and 1943301.

I believe the latest patch is bugfree as I have already tested the code a lot and fixed every problem I stumbled upon. Try it out yourself.

Kindest regards, J.

On Mon, Apr 21, 2008 at 5:48 PM, Hans-Christoph Steiner hans@eds.org wrote:

To start with, I think you should get a nice tight patch for switching garrays to using 'move' so we can see if this is really worth pursuing and what problems in might cause.

Please keep on experimenting with all things. But just so you know, if you want to get these patches included into pd-vanilla or pd-extended, they either need to be small or really well tested. So completely reworking garrays is probably something better attempting after we know that this core idea works out well (using move instead of delete/create).

.hc

------------------------------------------------------------------------ ----

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin