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

[Jakob Leben]

OK, I think I did it. Solved the slow garray drawing.

I introduced a new widgetbehavior of the same form as t_displacefn. All
children of a graph get their new widgetbehavior called from graph_displace.
That's way I called the new widgetbehavior t_graphfn, maybe we could find
something better to make clear the following notion: each object should
write into it's graphfn function only procedures to move it's graphical
content with calls to Tk command "move"; t_graphfn function provides in form
of it's arguments dx and dy to use with Tk move just as t_displacefn does
(graph_display passes it's dx and dy arguments on to every t_graphfn call it
makes).

I've filled in graphfn functions for everything connected with data
structures and arrays, it remains to write those functions for iemgui and
oldschool "text" objects. Coming soon. And for somebody who wants to write
new graphical externals the change will be almost invisible, because we can
make an iemgui_graph function to map to t_graphfn, that will call
x_gui.x_draw with IEM_GUI_DRAW_MODE_MOVE, so one really doesn't need to
write any more GUI code than before.

Performance is greatly improved, I can load 20secs of audio into an array
and it moves around a patch smoothly, though it demands it's 40-50% cpu. But
anyway, it works. I also tweaked some other pieces of code to remove
unnecessary multiple calls to garray_vis. I haven't yet tried if it disturbs
heavy audio processing when you load a large sample into an array. That's my
main concern with arrays to be honest.

So, what's the regime for spreading this code of mine into the wide world?
do you want to check it out? Shall I simply attach it to an email? Can I
upload the code somewhere?

J.

On Mon, Apr 14, 2008 at 7:19 PM, Hans-Christoph Steiner <hans at eds.org>
wrote:

>
> On Apr 14, 2008, at 6:28 AM, IOhannes m zmoelnig wrote:
>
> > Jakob Leben wrote:
> >
> > >
> > > If someone has thought on these proposals or any ideas, please
> > > comment.
> > >
> > >
> > not directly, but: does anybody know how one could setup a shared-memory
> > between pd and pd-gui?
> > i think it would be a good idea to not send large amounts of data
> > through a network socket.
> > (i had a look at [pix_preview] the other day, and noticed that it is not
> > really usable with larger image-data; shared-memory might be a solution
> > for this as well...)
> >
> > fmgasdr
> > IOhannes
> >
>
> For pix_preview, I was thinking, it could allocate two framebuffers and
> one lock variable.  In the lock variable would be the address of the
> framebuffer that is currently ready for Tcl to draw.  On the C side, it
> would be filling the other framebuffer in the meantime.  Once that is all
> done, it would change the lock variable to point to the new one.  This could
> be done with mmap and the lock variable would just be a filename, and the
> Tcl image object would just read the mmap'ed file for the image data.
>
> Just throwing it out there.
>
> .hc
>
>
> ----------------------------------------------------------------------------
>
> There is no way to peace, peace is the way.       -A.J. Muste
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080415/1a57cfa1/attachment.htm>