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
<[EMAIL PROTECTED]> 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
[email protected]
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
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
