Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
------------------------------------------------------------------------ ----
I rather doubt this can relly help given the way Pd uses Tcl/Tk. (I still have a pet idea on the other hand of simply parsing the TCL code and passing it to GTK :)
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
If Tcl_Obj references were sent via sys_vgui instead of Tcl code, I think you could reduce the network traffic down to like 10% of what it is now. Plus, using Tcl_Obj, each chunk of Tcl code would only be compiled once per run (the bytecode is stored as part of the Tcl_Obj). It's not going to change the world, but I think it would be noticeable.
.hc
On Mar 6, 2008, at 5:51 PM, Miller Puckette wrote:
I rather doubt this can relly help given the way Pd uses Tcl/Tk. (I still have a pet idea on the other hand of simply parsing the TCL code and passing it to GTK :)
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Thu, Mar 6, 2008 at 3:51 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
I rather doubt this can relly help given the way Pd uses Tcl/Tk. (I still have a pet idea on the other hand of simply parsing the TCL code and passing it to GTK :)
All those in favor of a GTK GUI for pd say I.
IIIIIII!
rich.
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On May 17, 2008, at 12:32 PM, Rich E wrote:
On Thu, Mar 6, 2008 at 3:51 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote: I rather doubt this can relly help given the way Pd uses Tcl/Tk. (I still have a pet idea on the other hand of simply parsing the TCL code and passing it to GTK :)
All those in favor of a GTK GUI for pd say I.
Honestly, Tcl/Tk does a much better job than GTK on Mac OS X and maybe Windows too. GTK apps look like, well, GTK apps. Tcl/Tk apps can be made to be quite native in feel. Tcl/Tk's big lack right now is native GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
.hc
IIIIIII!
rich.
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works
better
if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
--
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
Honestly, Tcl/Tk does a much better job than GTK on Mac OS X and maybe Windows too. GTK apps look like, well, GTK apps. Tcl/Tk apps can be made to be quite native in feel. Tcl/Tk's big lack right now is native GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
Have you tried Gnocl? http://www.dr-baum.net/gnocl/
On May 17, 2008, at 2:52 PM, Albert Graef wrote:
Hans-Christoph Steiner wrote:
Honestly, Tcl/Tk does a much better job than GTK on Mac OS X and maybe Windows too. GTK apps look like, well, GTK apps. Tcl/Tk apps can be made to be quite native in feel. Tcl/Tk's big lack right now is native GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
Have you tried Gnocl? http://www.dr-baum.net/gnocl/
Just saw that, looks like it'd do the trick, if anyone wants to take that on.
.hc
-- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
------------------------------------------------------------------------ ----
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hans-Christoph Steiner wrote:
GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
This has been a secret desire of mine for ages. Having access to the most-recent visited file list would be a huge bonus for linux. I spend 10 mins of every day navigating diectory trees while working in Pd.
On May 17, 2008, at 5:57 PM, Andy Farnell wrote:
Hans-Christoph Steiner wrote:
GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
This has been a secret desire of mine for ages. Having access to the most-recent visited file list would be a huge bonus for linux. I spend 10 mins of every day navigating diectory trees while working in Pd.
An "Open Recent" menu item would not be hard to add to Pd, if someone wanted to take that on. It could be a pure Tcl affair, so not too complicated. C would have to be involved if you wanted to additionally support any file opened with the [pd menuopen( message.
.hc
-- Use the source
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Honestly, Tcl/Tk does a much better job than GTK on Mac OS X and maybe Windows too. GTK apps look like, well, GTK apps. Tcl/Tk apps can be made to be quite native in feel.
I guess I am thinking more of functionality. I feel like I have hit a wall with pd's data structs, as the things I want to do are either impossible or too slow with tk (If anyone can think of a way to make a playhead auto scroll in a data-struct - score, I may stand corrected).
Personally, the thought of using cario or opengl widgets for controlling pd is appealing. So much that I am experimenting with a seperate app, coded in gtk/opengl, for controlling pd through OSC. I just don't see any reason why not to have it as the native pd GUI as well. Not that I can do it at present, or that cario/opengl will ever be in pd-vanilla, just dreaming.
Tcl/Tk's big lack right now is native GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
.hc
IIIIIII!
rich.
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Access to computers should be unlimited and total. - the hacker ethic
On May 18, 2008, at 10:49 AM, Rich E wrote:
Honestly, Tcl/Tk does a much better job than GTK on Mac OS X and maybe Windows too. GTK apps look like, well, GTK apps. Tcl/Tk apps can be made to be quite native in feel.
I guess I am thinking more of functionality. I feel like I have hit a wall with pd's data structs, as the things I want to do are either impossible or too slow with tk (If anyone can think of a way to make a playhead auto scroll in a data-struct - score, I may stand corrected).
Personally, the thought of using cario or opengl widgets for controlling pd is appealing. So much that I am experimenting with a seperate app, coded in gtk/opengl, for controlling pd through OSC. I just don't see any reason why not to have it as the native pd GUI as well. Not that I can do it at present, or that cario/ opengl will ever be in pd-vanilla, just dreaming.
I haven't look in-depth into the data structures drawing code, but if it is anything like the other drawing commands, then it uses delete/ create to move things. That's very slow. If it was changed to use "move" commands, it could be a lot faster.
.hc
Tcl/Tk's big lack right now is native GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
.hc
IIIIIII!
rich.
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance
differences.
Also, matju mentioned that the bytecode caching probably works
better
if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Access to computers should be unlimited and total. - the hacker ethic
------------------------------------------------------------------------ ----
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
-
Albert Graef -
Andy Farnell -
Hans-Christoph Steiner -
Miller Puckette -
Rich E