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

[Hans-Christoph Steiner]

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 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
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080421/fd66b243/attachment.htm>