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.<br>
<br>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. <br>
<br>Any suggestions?<br><br>Well, yeah, actually I did come up with one rather radical idea:<br>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...<br>
<br>...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.<br>
<br>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.<br>
<br>Sincerely,<br>J.<br><br><div class="gmail_quote">On Mon, Apr 21, 2008 at 5:20 AM, Mathieu Bouchard <<a href="mailto:matju@artengine.ca">matju@artengine.ca</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tue, 15 Apr 2008, Hans-Christoph Steiner wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
>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.<br>
</blockquote>
<br></div>
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.<br>
<font color="#888888">
<br>
_ _ __ ___ _____ ________ _____________ _____________________ ...<br>
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada</font></blockquote></div><br>