I've been working a bunch on GUIs recently, especially [entry], so I
decided to start a standard library: TkWidget. There are already a
number of half-complete Tk-based GUI objects in Pd (entry, popup,
ticker, button, image), this library aims to be a direct port of the
Tk widgets to Pd, with all of the Tk options exposed in Pd so that
they are very flexible and configurable.
I started a wiki page to start documenting ideas:
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc and if you would like to help with
this, join in! The next thing to for GUIs after this is to extend
tclpd so that you can write totally custom GUI objects completely in
Tcl/Tk.
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc this, join in! The next thing to for GUIs after this is to extend
tclpd so that you can write totally custom GUI objects completely in
is there something wrong with the [widget] external that made you want to reinvent it?
is [widget] worth fixing, but the rest of PD's GUI isnt?
On Oct 30, 2007, at 5:01 AM, cdr wrote:
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc this, join in! The next thing to for GUIs after this is to extend tclpd so that you can write totally custom GUI objects completely in
is there something wrong with the [widget] external that made you
want to reinvent it?
I think widget is great, I think of this as building upon that.
Combining Federico's tclpd + [widget] means writing full-fledged
native Pd objects in Tcl/Tk. Federico mentioned a problem with
[widget] in that the code runs only in the GUI process, he can speak
to that more. I'd like to see native objects rather than scripts in
the [widget] object.
is [widget] worth fixing, but the rest of PD's GUI isnt?
Both are worth doing, want to help? :)
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
For the gui-edit patch that I made some time ago to work perfectly, a
"state query" command would be necessary. Then it would be possible to
send the properties of each element to pd, and do whatever you want with
it.
How about also checking out if there would be any other alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated things (like
a gui element in a gop) take lots of cpu for what they give.
I've been working a bunch on GUIs recently, especially [entry], so I decided to start a standard library: TkWidget. There are already a number of half-complete Tk-based GUI objects in Pd (entry, popup, ticker, button, image), this library aims to be a direct port of the Tk widgets to Pd, with all of the Tk options exposed in Pd so that they are very flexible and configurable.
I started a wiki page to start documenting ideas:
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc and if you would like to help with this, join in! The next thing to for GUIs after this is to extend tclpd so that you can write totally custom GUI objects completely in Tcl/Tk.
How about also checking out if there would be any other alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated things (like
a gui element in a gop) take lots of cpu for what they give.
a lot of this has nothing to do with TCL/Tk being slow, but PD using C string manipulation to generate Tk commands..then piping them over the client<>server socket. many times a second, per object, in the audio thread. etc..
if you do similar things in HTML/JS/XUL you'll find them even slower than Tk, and using 10-100x the RAM. at least w/ firepig.
imo the biggest prob with [widget] is that the widgets were only 'alive' when that subpatch was physically on the screen. so some combination of tclpd and [widget] that has 'offscreen' mode which still allows data pass-thru and TCL execution would be an improvement...
On Wed, 31 Oct 2007, cdr wrote:
How about also checking out if there would be any other alternative to Tcl/Tk? It's still quite slow, and some not so uncomplicated things (like a gui element in a gop) take lots of cpu for what they give.
a lot of this has nothing to do with TCL/Tk being slow, but PD using C string manipulation to generate Tk commands..then piping them over the client<>server socket. many times a second, per object, in the audio thread. etc..
This is not what João is talking about. Yes, Tcl/Tk is slow, especially the Tk part. The problem with sending big Tcl commands over a socket all of the time, is that it's a bad separation of responsibility between threads ... but only people who want to modify the GUI itself might care about client-server separation of responsibility, and usually they don't.
The client-server separation happens to be a nice occasion to do consolidations of code such that it becomes easier to optimise, but it doesn't mean that the opportunity to do the optimisation itself has really been exploited so much by DesireData.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Oct 31, 2007, at 12:51 PM, Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, cdr wrote:
How about also checking out if there would be any other
alternative to Tcl/Tk? It's still quite slow, and some not so uncomplicated
things (like a gui element in a gop) take lots of cpu for what they give.a lot of this has nothing to do with TCL/Tk being slow, but PD
using C string manipulation to generate Tk commands..then piping
them over the client<>server socket. many times a second, per
object, in the audio thread. etc..This is not what João is talking about. Yes, Tcl/Tk is slow,
especially the Tk part. The problem with sending big Tcl commands
over a socket all of the time, is that it's a bad separation of
responsibility between threads ... but only people who want to
modify the GUI itself might care about client-server separation of
responsibility, and usually they don't.The client-server separation happens to be a nice occasion to do
consolidations of code such that it becomes easier to optimise, but
it doesn't mean that the opportunity to do the optimisation itself
has really been exploited so much by DesireData.
First off, Tcl/Tk 8.5 looks to have a lot of performance
improvements, especially on Mac OS X, as it shifts from Carbon/
QuickDraw to Cocoa/CoreGraphics.
Since we are talking about Tk now, I was wondering whether it would
be possible to use Tcl/Tk's C interface in some objects in order to
make things happen more efficiently.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
First off, Tcl/Tk 8.5 looks to have a lot of performance improvements, especially on Mac OS X, as it shifts from Carbon/QuickDraw to Cocoa/CoreGraphics.
I said that before. I'm claiming that Tcl/Tk 8.5 is too slow. Tcl/Tk 8.4 is even slower, mostly for OSX, but also, I suspect that the use of TrueType fonts takes more juice in general, but I haven't measured yet.
Since we are talking about Tk now, I was wondering whether it would be possible to use Tcl/Tk's C interface in some objects in order to make things happen more efficiently.
This is not where the bottleneck is.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Oct 31, 2007, at 3:12 PM, Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
First off, Tcl/Tk 8.5 looks to have a lot of performance
improvements, especially on Mac OS X, as it shifts from Carbon/ QuickDraw to Cocoa/CoreGraphics.I said that before. I'm claiming that Tcl/Tk 8.5 is too slow. Tcl/ Tk 8.4 is even slower, mostly for OSX, but also, I suspect that the
use of TrueType fonts takes more juice in general, but I haven't
measured yet.Since we are talking about Tk now, I was wondering whether it
would be possible to use Tcl/Tk's C interface in some objects in
order to make things happen more efficiently.This is not where the bottleneck is.
I thought the network socket was the bottleneck. The example I am
thinking of is getting the mouse pointer coords from Tk. That
generates a lot of network traffic, it would be nice this happened in
the pd process instead. Obviously, using the C interface to draw to
the screen wouldn't be useful.
.hc
Access to computers should be unlimited and total. - the hacker ethic
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
This is not where the bottleneck is.
I thought the network socket was the bottleneck. The example I am thinking of is getting the mouse pointer coords from Tk. That generates a lot of network traffic, it would be nice this happened in the pd process instead. Obviously, using the C interface to draw to the screen wouldn't be useful.
What I wrote to Carmen is because I think that the network socket is not the bottleneck, so I told what I think the problem is about the network socket.
The bottleneck is most of all the Tk rendering itself.
Something that may make one think that the bottleneck is in the network socket, is that when the Tk rendering takes too much time, it saturates the pipe, which causes (or caused) pd to pause waiting for the Tcl/Tk process to be less busy.
I think that since 0.38 or so, if the Tcl/Tk process is continually too busy, Pd grows the output socket queue until Pd blows up by out-of-memory.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hans-Christoph Steiner wrote:
On Oct 31, 2007, at 3:12 PM, Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
First off, Tcl/Tk 8.5 looks to have a lot of performance improvements, especially on Mac OS X, as it shifts from Carbon/ QuickDraw to Cocoa/CoreGraphics.
I said that before. I'm claiming that Tcl/Tk 8.5 is too slow. Tcl/ Tk 8.4 is even slower, mostly for OSX, but also, I suspect that the use of TrueType fonts takes more juice in general, but I haven't measured yet.
Since we are talking about Tk now, I was wondering whether it would be possible to use Tcl/Tk's C interface in some objects in order to make things happen more efficiently.
This is not where the bottleneck is.
I thought the network socket was the bottleneck. The example I am thinking of is getting the mouse pointer coords from Tk. That generates a lot of network traffic, it would be nice this happened in the pd process instead. Obviously, using the C interface to draw to the screen wouldn't be useful.
Maybe if redundant calls could be pruned before going through the socket things would work better. For instance if a number box is being updated a few hundred times a second then it would be better if only the last update per signal block would get through.
Martin
On Wed, 31 Oct 2007, Martin Peach wrote:
Maybe if redundant calls could be pruned before going through the socket things would work better. For instance if a number box is being updated a few hundred times a second then it would be better if only the last update per signal block would get through.
They already are, but just the builtin objects, *not* including IEMGUI. However, the way that they are pruned, they are sometimes not updated often: the appearance of a floatbox can hang while the server is too busy.
In contrast, DesireData has a minimum update rate of 50 ms of logical time. I can see tweaking that further, so that it is 50 ms of real time, or any other value of logical time or real time, and/or setting a max number of box updates per pass, or a max number of bytes of updates per pass.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, Martin Peach wrote:
Maybe if redundant calls could be pruned before going through the socket things would work better. For instance if a number box is being updated a few hundred times a second then it would be better if only the last update per signal block would get through.
They already are, but just the builtin objects, *not* including IEMGUI. However, the way that they are pruned, they are sometimes not updated often: the appearance of a floatbox can hang while the server is too busy.
In contrast, DesireData has a minimum update rate of 50 ms of logical time. I can see tweaking that further, so that it is 50 ms of real time, or any other value of logical time or real time, and/or setting a max number of box updates per pass, or a max number of bytes of updates per pass.
It doesn't make sense to update a box or the screen more often than once per frame on the viewing device, but of course that signal (the vertical retrace or frame sync) is often hard to obtain. openGL sometimes has it builtin, does tk? 60Hz is 16.66...ms.
Martin
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often than once per frame on the viewing device, but of course that signal (the vertical retrace or frame sync) is often hard to obtain. openGL sometimes has it builtin, does tk? 60Hz is 16.66...ms.
I'm not recommending to make it go at a rate above the monitor's rate. Usually, even a third of the monitor's rate is too much for Tk. I'm not 100% sure what is Tk's refresh rate, I think I've seen 50 ms (20 Hz). I don't think it ever checks the monitor's rate.
I thought you were suggesting to use the audio block size?... anyhow, surely not, as it's much above the frequency of the monitor.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often than once per frame on the viewing device, but of course that signal (the vertical retrace or frame sync) is often hard to obtain. openGL sometimes has it builtin, does tk? 60Hz is 16.66...ms.
I'm not recommending to make it go at a rate above the monitor's rate. Usually, even a third of the monitor's rate is too much for Tk. I'm not 100% sure what is Tk's refresh rate, I think I've seen 50 ms (20 Hz). I don't think it ever checks the monitor's rate.
I thought you were suggesting to use the audio block size?... anyhow, surely not, as it's much above the frequency of the monitor.
I guess from pd's point of view the audio block determines the granularity of time, and messages are processed in between audio blocks, so it would be more difficult to synchronize drawing to another similar frequency. It seems like tk's drawing is opaque to the programmer in terms of exactly when it takes place, so then the network messages between pd and tk should be filtered at some multiple of the audio block that is similar to the screen rate. I mean for instance that only the last received command to a number box should be sent across the connection for each "display block". It may turn out that scanning the queue takes longer than just sending it all. Maybe it should be up to tk to filter the extra commands. Maybe it already does.
Martin
On Nov 1, 2007, at 1:06 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often
than once per frame on the viewing device, but of course that signal (the
vertical retrace or frame sync) is often hard to obtain. openGL sometimes
has it builtin, does tk? 60Hz is 16.66...ms.I'm not recommending to make it go at a rate above the monitor's
rate. Usually, even a third of the monitor's rate is too much for Tk.
I'm not 100% sure what is Tk's refresh rate, I think I've seen 50 ms (20
Hz). I don't think it ever checks the monitor's rate.I thought you were suggesting to use the audio block size?... anyhow, surely not, as it's much above the frequency of the monitor.
I guess from pd's point of view the audio block determines the
granularity of time, and messages are processed in between audio blocks, so it
would be more difficult to synchronize drawing to another similar frequency.
It seems like tk's drawing is opaque to the programmer in terms of exactly
when it takes place, so then the network messages between pd and tk should be filtered at some multiple of the audio block that is similar to the
screen rate. I mean for instance that only the last received command to a
number box should be sent across the connection for each "display block".
It may turn out that scanning the queue takes longer than just sending it
all. Maybe it should be up to tk to filter the extra commands. Maybe it
already does.
Even tho the screen updates at least evern 16ms, most GUI object do
not benefit from that at all. For example, number boxes would be
totally fine updating every 100ms or more, unless you like the look
of blurry numbers flying by. Sliders and buttons probably would be
fine at 50ms also
It would be nice to have this as part of the GUI API, so that it is
easy to use.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Even tho the screen updates at least evern 16ms, most GUI object do not benefit from that at all. For example, number boxes would be totally fine updating every 100ms or more, unless you like the look of blurry numbers flying by. Sliders and buttons probably would be fine at 50ms also
It would be nice to have this as part of the GUI API, so that it is easy to use.
if things are being improved, a principle that I find important is the
possibility to unlock these settings to general use. that is, instead of
just improving them, for example creating a command "displayfr" or
whatever that each object could understand. then instead of locking the
parameters in a different setting, more possibilities are possible. (or
would something like that imply too much work?)
for what its worth, Max has a preference that sets the frequency of
all screen refreshes of patcher objects. This can be useful to reduce
GUI overhead on heavy patches.
On Nov 3, 2007, at 5:05 PM, João Miguel Pais wrote:
Even tho the screen updates at least evern 16ms, most GUI object do not benefit from that at all. For example, number boxes would be totally fine updating every 100ms or more, unless you like the look of blurry numbers flying by. Sliders and buttons probably would be fine at 50ms also
It would be nice to have this as part of the GUI API, so that it is easy to use.
if things are being improved, a principle that I find important is the possibility to unlock these settings to general use. that is,
instead of just improving them, for example creating a command "displayfr" or whatever that each object could understand. then instead of locking
the parameters in a different setting, more possibilities are possible.
(or would something like that imply too much work?)
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 1, 2007, at 12:20 PM, Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often
than once per frame on the viewing device, but of course that
signal (the vertical retrace or frame sync) is often hard to
obtain. openGL sometimes has it builtin, does tk? 60Hz is 16.66...ms.I'm not recommending to make it go at a rate above the monitor's
rate. Usually, even a third of the monitor's rate is too much for
Tk. I'm not 100% sure what is Tk's refresh rate, I think I've seen
50 ms (20 Hz). I don't think it ever checks the monitor's rate.I thought you were suggesting to use the audio block size?...
anyhow, surely not, as it's much above the frequency of the monitor.
Using my new [cursor] object and [timer], I was getting mouse motion
events every 17-19ms.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On Oct 31, 2007, at 4:45 AM, cdr wrote:
How about also checking out if there would be any other
alternative to Tcl/Tk? It's still quite slow, and some not so uncomplicated
things (like a gui element in a gop) take lots of cpu for what they give.a lot of this has nothing to do with TCL/Tk being slow, but PD
using C string manipulation to generate Tk commands..then piping
them over the client<>server socket. many times a second, per
object, in the audio thread. etc..if you do similar things in HTML/JS/XUL you'll find them even
slower than Tk, and using 10-100x the RAM. at least w/ firepig.imo the biggest prob with [widget] is that the widgets were only
'alive' when that subpatch was physically on the screen. so some
combination of tclpd and [widget] that has 'offscreen' mode which
still allows data pass-thru and TCL execution would be an
improvement...
You have the best understanding of [widget] so it would be excellent
to apply that to tclpd. Any interest in helping? I am not good at
Tcl/Tk, but I think it would be a very useful thing to have in Pd, so
I am planning on doing what I can. Now that I have a better grasp of
Pd's GUI API, I have just started to think about how to make a tclpd
API. Federico and I talked briefly about it, maybe he's been
inspired recently.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Wed, 31 Oct 2007, João Miguel Pais wrote:
How about also checking out if there would be any other alternative to Tcl/Tk? It's still quite slow, and some not so uncomplicated things (like a gui element in a gop) take lots of cpu for what they give.
I think that it's easier to work on customising Tk itself, than to find a replacement for Tk.
I've tried a few quick changes to Tk and sometimes they make huge improvements. I've got more ideas to try. The main problem with Tk until PdConvention2007 was that no Pd user had ever tried modifying the Tk source code. The situation isn't much better now, but I still have hope that if I try my other ideas I will get somewhere.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
The state query is a very good idea, feel like adding it to the wiki? :)
.hc
On Oct 31, 2007, at 8:26 AM, João Miguel Pais wrote:
For the gui-edit patch that I made some time ago to work perfectly,
a "state query" command would be necessary. Then it would be
possible to send the properties of each element to pd, and do
whatever you want with it.How about also checking out if there would be any other alternative
to Tcl/Tk? It's still quite slow, and some not so uncomplicated
things (like a gui element in a gop) take lots of cpu for what they
give.I've been working a bunch on GUIs recently, especially [entry], so I decided to start a standard library: TkWidget. There are already a number of half-complete Tk-based GUI objects in Pd (entry, popup, ticker, button, image), this library aims to be a direct port of the Tk widgets to Pd, with all of the Tk options exposed in Pd so that they are very flexible and configurable.
I started a wiki page to start documenting ideas:
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc and if you would like to help with this, join in! The next thing to for GUIs after this is to extend tclpd so that you can write totally custom GUI objects completely in Tcl/Tk.
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
-
cdr -
Hans-Christoph Steiner -
João Miguel Pais -
Martin Peach -
Mathieu Bouchard -
vade