Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
> 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
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
> 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... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] TkWidget library
> 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? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] TkWidget library
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
