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.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
_______________________________________________
PD-dev mailing list
----------------------------------------------------------------------------
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