[PD-dev] Fwd: [MACTCL] Improving Application GUI Speed

[Jakob Leben]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080421/81c5a131/attachment.htm>