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: <br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>I've uploaded the patch:<br><a href="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</a><br>
<br>J.<br><br><div class="gmail_quote">On Tue, Apr 15, 2008 at 7:11 PM, Hans-Christoph Steiner <<a href="mailto:hans@eds.org">hans@eds.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">
<div><br></div><div>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:</div><div><br></div><div><a href="http://puredata.info/dev/patchtracker" target="_blank">http://puredata.info/dev/patchtracker</a></div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div><div><br></div><div>Thanks for taking this on, it is a very valuable contribution!</div>
<div><br></div><font color="#888888"><div>.hc</div></font><div><div></div><div class="Wj3C7c"><div><br></div><div><br></div><div>On Apr 15, 2008, at 1:04 AM, Jakob Leben wrote:<br><blockquote type="cite">OK, I think I did it. Solved the slow garray drawing.<br>
<br>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).<br>
<br>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.<br>
<br>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.<br>
<br>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?<br><br>J.<br><br><div class="gmail_quote">
On Mon, Apr 14, 2008 at 7:19 PM, Hans-Christoph Steiner <<a href="mailto:hans@eds.org" target="_blank">hans@eds.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div><br> On Apr 14, 2008, at 6:28 AM, IOhannes m zmoelnig wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Jakob Leben wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br> If someone has thought on these proposals or any ideas, please comment.<br> <br> </blockquote> <br> not directly, but: does anybody know how one could setup a shared-memory<br> between pd and pd-gui?<br> i think it would be a good idea to not send large amounts of data<br>
through a network socket.<br> (i had a look at [pix_preview] the other day, and noticed that it is not<br> really usable with larger image-data; shared-memory might be a solution<br> for this as well...)<br> <br> fmgasdr<br>
IOhannes<br> </blockquote> <br></div></div> 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.<br>
<br> Just throwing it out there.<br> <br> .hc<br> <br> ----------------------------------------------------------------------------<br> <br> There is no way to peace, peace is the way. -A.J. Muste<br> <br> <br> </blockquote>
</div><br></blockquote></div><br></div></div><div> <span style="border-collapse: separate; border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br>
<div class="Ih2E3d"><div><br></div><div>----------------------------------------------------------------------------</div><div><br></div><div>Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra</div>
<br></div></span> </div><br></div></blockquote></div><br>