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

[cyrille henry]

hello,

this patch is great.
i hope miller will accept it!

thanks

Cyrille


Jakob Leben a écrit :
> I will think of doing it the displace_fn way. Though my first thoughts 
> are sort of equally sceptic as your critique of including new 
> widgetbehavior:
> 
> Displacefn functions usually either create or delete graphics, so to 
> "displace" the graphics you usually call it twice: first with vis = 0 to 
> erase the graphics and then again with vis = 1 to recreate the graphics. 
> Now, to implement new style of moving graphics we could call the 
> displace_fn with a new value for it's vis argument which would require 
> displace_fn to act accoringly to this flag. But displace_fn functions 
> usually only check if "vis" = true or false, so all the objects that 
> wouldn't have a dedicated interpretation of our new vis value would 
> either erase their graphics and never draw it again, or create it again 
> without the old being erased. Which means again that for the system to 
> function properly all the GUI objects should have their displace_fn 
> functions modified.
> 
>  From this perspective it looks to me better to make a dedicated 
> widgetbehavior. This way when compiling some code that wouldn't have 
> this widgetbehavior initialized you at least get a warning from 
> compiler, or on the other hand pd crashes when calling the uninitialized 
> widgetbehavior and you know for sure that something is wrong.
> 
> Plus, do you think there's a large amount of GUI externals? I think a 
> big many of externals only have basic "t_text" graphical represantion. 
> And I have already written displace_fn functions for all the pd vanilla 
> GUI classes.
> 
> I've uploaded the patch:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1943301&group_id=55736&atid=478072 
> <http://sourceforge.net/tracker/index.php?func=detail&aid=1943301&group_id=55736&atid=478072>
> 
> J.
> 
> On Tue, Apr 15, 2008 at 7:11 PM, Hans-Christoph Steiner <hans at eds.org 
> <mailto:hans at eds.org>> wrote:
> 
> 
>     Sounds interesting, you can post the code here in the email.  If it
>     is a patch against Pd, then you can submit it to the patch tracker:
> 
>     http://puredata.info/dev/patchtracker
> 
>      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. 
> 
>     Perhaps there is a way of implementing this in the displace_fn?
>      IIRC, the displace_fn is meant for moving already, so no need to
>     define a new move function.
> 
>     Thanks for taking this on, it is a very valuable contribution!
> 
>     .hc
> 
> 
>     On Apr 15, 2008, at 1:04 AM, Jakob Leben wrote:
>>     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 <mailto: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
>>
>>
>>
> 
> 
> 
>     ----------------------------------------------------------------------------
> 
>     Computer science is no more related to the computer than astronomy
>     is related to the telescope.      -Edsger Dykstra
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev