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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
