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]> 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
