Hello list reading everywhere that GUI takes enormous amount of CPU.
More precisely : does a GUI element, say a slider monitoring a signal, require lots of CPU in anycase -even when for instance it is invisible somewhere deep in a subpatch-, or is it requiring lots of CPU only when displayed in front window ? JmA
From my experience I'd say that GUI elements only take up a lot of
resources when redrawing is required. A passive slider doesn't require a lot of CPU (if at all), but it does when you move it. The more complex the GUI element, the more power is required. One typical use of GUI you want to avoid if your machine has limited resources is long arrays that would be redrawn all the time (like in an oscilloscope).
Pierre.
2012/2/8 Jean-Marie Adrien jma@jeanmarie-adrien.net
Hello list reading everywhere that GUI takes enormous amount of CPU.
More precisely : does a GUI element, say a slider monitoring a signal, require lots of CPU in anycase -even when for instance it is invisible somewhere deep in a subpatch-, or is it requiring lots of CPU only when displayed in front window ? JmA _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi
See attached patch. Open it, turn on DSP, click the toggle and compare CPU usage with the subpatch visible or hidden. On my computer, Pd takes 1% of CPU with the non-visible slider, and between 2 and 3% when the slider is visible. Remember that [bang~] bangs at audio rate :) I usually limit slider and al refresh request rate to 20ms or more : or better, once the patch runs ok, i delete all useless sliders, bangs and toggles.
On 08/02/2012 15:41, Jean-Marie Adrien wrote:
Hello list reading everywhere that GUI takes enormous amount of CPU.
More precisely : does a GUI element, say a slider monitoring a signal, require lots of CPU in anycase -even when for instance it is invisible somewhere deep in a subpatch-, or is it requiring lots of CPU only when displayed in front window ? JmA _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One thing to keep in mind with Pd on modern computers is that 'pd-gui' is a totally separate process from 'pd', so since basically all laptops, desktops, and even tablets these days ship with 2 or more cores, that means 'pd-gui' and 'pd' will be running on separate cores. Therefore, as long as 'pd-gui' doesn't use more than say 70% of one core, it shouldn't affect 'pd' much at all.
.hc
On Wed, 2012-02-08 at 17:01 +0100, batinste wrote:
Hi
See attached patch. Open it, turn on DSP, click the toggle and compare CPU usage with the subpatch visible or hidden. On my computer, Pd takes 1% of CPU with the non-visible slider, and between 2 and 3% when the slider is visible. Remember that [bang~] bangs at audio rate :) I usually limit slider and al refresh request rate to 20ms or more : or better, once the patch runs ok, i delete all useless sliders, bangs and toggles.
On 08/02/2012 15:41, Jean-Marie Adrien wrote:
Hello list reading everywhere that GUI takes enormous amount of CPU.
More precisely : does a GUI element, say a slider monitoring a signal, require lots of CPU in anycase -even when for instance it is invisible somewhere deep in a subpatch-, or is it requiring lots of CPU only when displayed in front window ? JmA _______________________________________________ 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
While technically correct that's misleading because there's a lot of stuff happening on the 'pd' side
that a reasonable person would assume to be handled on the 'pd-gui' side. Well, more than that--
there's stuff happening on the 'pd' side that doesn't need to happen at all, but it can use massive
amounts of CPU and consequently a reasonable person gets dropouts when moving an array that
has only 100 points visible and erroneously thinks, "Wow, I get dropouts just moving some
polygons around on the screen? Tk stinks!"
-Jonathan
From: Hans-Christoph Steiner hans@at.or.at To: batinste dwanafite@yahoo.fr Cc: "pd-list@iem.at List" pd-list@iem.at Sent: Wednesday, February 8, 2012 12:38 PM Subject: Re: [PD] GUI and DSP
One thing to keep in mind with Pd on modern computers is that 'pd-gui' is a totally separate process from 'pd', so since basically all laptops, desktops, and even tablets these days ship with 2 or more cores, that means 'pd-gui' and 'pd' will be running on separate cores. Therefore, as long as 'pd-gui' doesn't use more than say 70% of one core, it shouldn't affect 'pd' much at all.
.hc
On Wed, 2012-02-08 at 17:01 +0100, batinste wrote:
Hi
See attached patch. Open it, turn on DSP, click the toggle and compare CPU usage with the subpatch visible or hidden. On my computer, Pd takes 1% of CPU with the non-visible slider, and between 2 and 3% when the slider is visible. Remember that [bang~] bangs at audio rate :) I usually limit slider and al refresh request rate to 20ms or more : or better, once the patch runs ok, i delete all useless sliders, bangs and toggles.
On 08/02/2012 15:41, Jean-Marie Adrien wrote:
Hello list reading everywhere that GUI takes enormous amount of CPU.
More precisely : does a GUI element, say a slider monitoring a signal, require lots of CPU in anycase -even when for instance it is invisible somewhere deep in a subpatch-, or is it requiring lots of CPU only when displayed in front window ? JmA _______________________________________________ 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because there's a lot of stuff happening on the 'pd' side that a reasonable person would assume to be handled on the 'pd-gui' side. Well, more than that-- there's stuff happening on the 'pd' side that doesn't need to happen at all, but it can use massive amounts of CPU and consequently a reasonable person gets dropouts when moving an array that has only 100 points visible and erroneously thinks, "Wow, I get dropouts just moving some polygons around on the screen? Tk stinks!"
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d" when you can use "%x" and similar... especially fixed-width %x such as "%04x".
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Mathieu Bouchard matju@artengine.ca wrote:
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because there's a lot of stuff happening on the 'pd' side that a reasonable person would
assume
to be handled on the 'pd-gui' side. Well, more than that-- there's stuff happening on the 'pd' side that doesn't need to happen at all,
but
it can use massive amounts of CPU and consequently a reasonable
person
gets dropouts when moving an array that has only 100 points visible
and
erroneously thinks, "Wow, I get dropouts just moving some polygons around on the screen? Tk stinks!"
Or you could simply use pd-l2ork and a move arrays and other complex graphical user interface objects using tags and never worry about that problem again.
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d"
when you can use "%x" and similar... especially fixed-width %x such as "%04x".
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Hmm, thanks ! Sorry i was just wondering wether i had to erase all my signal driven sliders deep in subpatches :)) ...got some info thus, thanks, i love this list JmAdrien
Le 8 févr. 2012 à 21:33, Ivica Ico Bukvic ico@vt.edu a écrit :
Mathieu Bouchard matju@artengine.ca wrote:
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because there's a lot of stuff happening on the 'pd' side that a reasonable person would
assume
to be handled on the 'pd-gui' side. Well, more than that-- there's stuff happening on the 'pd' side that doesn't need to happen at all,
but
it can use massive amounts of CPU and consequently a reasonable
person
gets dropouts when moving an array that has only 100 points visible
and
erroneously thinks, "Wow, I get dropouts just moving some polygons around on the screen? Tk stinks!"
Or you could simply use pd-l2ork and a move arrays and other complex graphical user interface objects using tags and never worry about that problem again.
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d"
when you can use "%x" and similar... especially fixed-width %x such as "%04x".
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-02-08 à 15:33:00, Ivica Ico Bukvic a écrit :
Mathieu Bouchard matju@artengine.ca wrote: Or you could simply use pd-l2ork and a move arrays and other complex graphical user interface objects using tags and never worry about that problem again.
But arrays can still update quite quickly and it would be good if their data could be sent faster. So, what I'm saying also applies to l2ork, just not in the context of moving objects.
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d" when you can use "%x" and similar... especially fixed-width %x such as "%04x".
Actually, I mentioned fixed-width because then, you don't have to transmit space separators at all... except if you fear long lines.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Mathieu Bouchard matju@artengine.ca; Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at List" pd-list@iem.at Sent: Wednesday, February 8, 2012 3:33 PM Subject: Re: [PD] GUI and DSP
Mathieu Bouchard matju@artengine.ca wrote:
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because there's a
lot of
stuff happening on the 'pd' side that a reasonable person would
assume
to be handled on the 'pd-gui' side. Well, more than that--
there's
stuff happening on the 'pd' side that doesn't need to
happen at all,
but
it can use massive amounts of CPU and consequently a reasonable
person
gets dropouts when moving an array that has only 100 points visible
and
erroneously thinks, "Wow, I get dropouts just moving some polygons
around on the screen? Tk stinks!"
Or you could simply use pd-l2ork and a move arrays and other complex graphical user interface objects using tags and never worry about that problem again.
But even in pd l2ork, if you have a million element array with 100 elements showing, every time you click-drag a point in the array 'pd' recalculates the relationship between points/elements for the _entire_ array, right? At least that's what the code in g_array.c looked like it was doing when I last looked at it.
If I understand it correctly, the 'pd-gui' waits for that c code to loop through the entire array before it updates-- thus if you swoop the mouse through the entire array it may look like a sluggish redrawing on Tk's part when actually it's redrawing just fine once it gets the new coords, which takes time (and can cause dropouts).
That's a purposely exaggerated example, as it doesn't make a lot of sense to draw a 100-point garray that represents a 1000000-element array. But it makes me wonder whether the "strobing" effect you get with a ds-array that has a lot of elements happens because of similar heavy processing on the c side of things.
Has anyone tried to make a big polygon with lots of moving parts purely in tcl/tk and measured the cpu? Might help to see Tk's limits separated out from pd.
-Jonathan
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g"
nor "%d"
when you can use "%x" and similar... especially fixed-width %x
such as
"%04x".
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
On Feb 8, 2012, at 6:03 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Mathieu Bouchard matju@artengine.ca; Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at List" pd-list@iem.at Sent: Wednesday, February 8, 2012 3:33 PM Subject: Re: [PD] GUI and DSP
Mathieu Bouchard matju@artengine.ca wrote:
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because there's a
lot of
stuff happening on the 'pd' side that a reasonable person would
assume
to be handled on the 'pd-gui' side. Well, more than that--
there's
stuff happening on the 'pd' side that doesn't need to
happen at all,
but
it can use massive amounts of CPU and consequently a reasonable
person
gets dropouts when moving an array that has only 100 points visible
and
erroneously thinks, "Wow, I get dropouts just moving some polygons
around on the screen? Tk stinks!"
Or you could simply use pd-l2ork and a move arrays and other complex graphical user interface objects using tags and never worry about that problem again.
But even in pd l2ork, if you have a million element array with 100 elements showing, every time you click-drag a point in the array 'pd' recalculates the relationship between points/elements for the _entire_ array, right? At least that's what the code in g_array.c looked like it was doing when I last looked at it.
If I understand it correctly, the 'pd-gui' waits for that c code to loop through the entire array before it updates-- thus if you swoop the mouse through the entire array it may look like a sluggish redrawing on Tk's part when actually it's redrawing just fine once it gets the new coords, which takes time (and can cause dropouts).
That's a purposely exaggerated example, as it doesn't make a lot of sense to draw a 100-point garray that represents a 1000000-element array. But it makes me wonder whether the "strobing" effect you get with a ds-array that has a lot of elements happens because of similar heavy processing on the c side of things.
Has anyone tried to make a big polygon with lots of moving parts purely in tcl/tk and measured the cpu? Might help to see Tk's limits separated out from pd.
I just made a pure Tcl array like thing. I made two versions, one using the create/delete technique that Pd uses, and another that uses the "coords" canvas command to update an existing line. They both seem to use about 45% of my CPU on Mac OS X 10.6.8 running Tcl/Tk/Carbon 8.5.10. Using Tcl/Tk/Cocoa 8.5.8 uses about the same, maybe a little less. Since the Tcl/Tk canvas is on the main CPU, and not the GPU, its not going to be particularly fast at such things.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Ivica Ico Bukvic ico@vt.edu; Mathieu Bouchard matju@artengine.ca; "pd-list@iem.at List" pd-list@iem.at Sent: Friday, February 10, 2012 10:48 PM Subject: Re: [PD] GUI and DSP
On Feb 8, 2012, at 6:03 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Mathieu Bouchard matju@artengine.ca; Jonathan Wilkes
Cc: "pd-list@iem.at List" pd-list@iem.at Sent: Wednesday, February 8, 2012 3:33 PM Subject: Re: [PD] GUI and DSP
Mathieu Bouchard matju@artengine.ca wrote:
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because
there's a
lot of
stuff happening on the 'pd' side that a reasonable
person would
assume
to be handled on the 'pd-gui' side. Well, more than
that--
there's
stuff happening on the 'pd' side that doesn't need
to
happen at all,
but
it can use massive amounts of CPU and consequently a reasonable
person
gets dropouts when moving an array that has only 100 points
visible
and
erroneously thinks, "Wow, I get dropouts just moving some
polygons
around on the screen? Tk stinks!"
Or you could simply use pd-l2ork and a move arrays and other complex
graphical
user interface objects using tags and never worry about that problem
again.
But even in pd l2ork, if you have a million element array with 100 elements
showing,
every time you click-drag a point in the array 'pd' recalculates
the relationship between
points/elements for the _entire_ array, right? At least that's what
the code in g_array.c
looked like it was doing when I last looked at it.
If I understand it correctly, the 'pd-gui' waits for that c code to
loop through the entire array before
it updates-- thus if you swoop the mouse through the entire array it may
look like a
sluggish redrawing on Tk's part when actually it's redrawing just
fine once it gets the
new coords, which takes time (and can cause dropouts).
That's a purposely exaggerated example, as it doesn't make a lot of
sense to draw a
100-point garray that represents a 1000000-element array. But it makes me
wonder
whether the "strobing" effect you get with a ds-array that has a
lot of elements
happens because of similar heavy processing on the c side of things.
Has anyone tried to make a big polygon with lots of moving parts purely in
tcl/tk and
measured the cpu? Might help to see Tk's limits separated out from pd.
I just made a pure Tcl array like thing. I made two versions, one using the create/delete technique that Pd uses, and another that uses the "coords" canvas command to update an existing line. They both seem to use about 45% of my CPU on Mac OS X 10.6.8 running Tcl/Tk/Carbon 8.5.10. Using Tcl/Tk/Cocoa 8.5.8 uses about the same, maybe a little less. Since the Tcl/Tk canvas is on the main CPU, and not the GPU, its not going to be particularly fast at such things.
Ah, nice!
For me the create-delete method uses more CPU but both are pretty intensive.
Any Qt devs out there? Or gtk'ers? Maybe a JUCEr? Would those toolkits be able to utilize the GPU? Those would be nice to compare, too.
-Jonathan
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Le 2012-02-10 à 20:09:00, Jonathan Wilkes a écrit :
For me the create-delete method uses more CPU but both are pretty intensive. Any Qt devs out there? Or gtk'ers? Maybe a JUCEr? Would those toolkits be able to utilize the GPU? Those would be nice to compare, too.
In the end, switching toolkits wouldn't be a bad idea, but it's not the only solution. Some things inside of tk could be improved. Modifying tk can be scary, more so if we have to think seriously about bundling alpha versions of tk 8.7 together with pd-extended, but the alternative is to rewrite large amounts of code (everything using sys_gui or implicitly referring to Tcl), which is error-prone, hard to test, and too many changes in one chunk.
So, it's not very clear to me which one is best.
I had tried making some changes to Tk 8.5, and it seemed somewhat promising. I was getting large speedups for some cases, and large slowdowns for some other cases. With more work, the latter could have been eliminated. It would benefit most other uses of Tk Canvas in other apps as well, so it could be integrated to Tk itself.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; Ivica Ico Bukvic ico@vt.edu; "pd-list@iem.at List" pd-list@iem.at Sent: Saturday, February 11, 2012 11:59 AM Subject: Re: [PD] GUI and DSP
Le 2012-02-10 à 20:09:00, Jonathan Wilkes a écrit :
For me the create-delete method uses more CPU but both are pretty
intensive. Any Qt devs out there? Or gtk'ers? Maybe a JUCEr? Would those toolkits be able to utilize the GPU? Those would be nice to compare, too.
In the end, switching toolkits wouldn't be a bad idea, but it's not the only solution. Some things inside of tk could be improved. Modifying tk can be scary, more so if we have to think seriously about bundling alpha versions of tk 8.7 together with pd-extended, but the alternative is to rewrite large amounts of code (everything using sys_gui or implicitly referring to Tcl), which is error-prone, hard to test, and too many changes in one chunk.
So, it's not very clear to me which one is best.
I had tried making some changes to Tk 8.5, and it seemed somewhat promising. I was getting large speedups for some cases, and large slowdowns for some other cases. With more work, the latter could have been eliminated. It would benefit most other uses of Tk Canvas in other apps as well, so it could be integrated to Tk itself.
Do you still have any of those changes you made to Tk? If so, how do they compare to unpatched Tk when running Hans' array-demo?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
JUCE is amazing in terms of gui speed-up. Just check out bundled demos that come with the sdk... Half of Gem could be easily reimplemented using JUCE sdk...
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; Ivica Ico Bukvic ico@vt.edu; "pd-list@iem.at List" pd-list@iem.at Sent: Saturday, February 11, 2012 11:59 AM Subject: Re: [PD] GUI and DSP
Le 2012-02-10 à 20:09:00, Jonathan Wilkes a écrit :
For me the create-delete method uses more CPU but both are pretty
intensive. Any Qt devs out there? Or gtk'ers? Maybe a JUCEr? Would those toolkits be able to utilize the GPU? Those would be nice to compare, too.
In the end, switching toolkits wouldn't be a bad idea, but it's not the only solution. Some things inside of tk could be improved. Modifying tk can be scary, more so if we have to think seriously about bundling alpha versions of tk 8.7 together with pd-extended, but the alternative is to rewrite large amounts of code (everything using sys_gui or implicitly referring to Tcl), which is error-prone, hard to test, and too many changes in one chunk.
So, it's not very clear to me which one is best.
I had tried making some changes to Tk 8.5, and it seemed somewhat promising. I was getting large speedups for some cases, and large slowdowns for some other cases. With more work, the latter could have been eliminated. It would benefit most other uses of Tk Canvas in other apps as well, so it could be integrated to Tk itself.
Do you still have any of those changes you made to Tk? If so, how do they compare to unpatched Tk when running Hans' array-demo?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-11 à 13:58:00, Ivica Ico Bukvic a écrit :
JUCE is amazing in terms of gui speed-up. Just check out bundled demos that come with the sdk... Half of Gem could be easily reimplemented using JUCE sdk...
Looks nice, but the window border of JuceDemo is weird. JuceDemo disables the WM-made border, and puts its own border, which doesn't seem to interpret «Maximise» the same way that the WM does, and is perhaps even buggy.
And what would be the cause of JUCE being slow on some computers ? I don't think that it would be acceptable that JUCE be mysteriously slow on some computers that aren't even old (if that's really what's happening).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Ivica Ico Bukvic ico@vt.edu Cc: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at List" pd-list@iem.at Sent: Saturday, February 18, 2012 2:06 PM Subject: Re: [PD] GUI and DSP
Le 2012-02-11 à 13:58:00, Ivica Ico Bukvic a écrit :
JUCE is amazing in terms of gui speed-up. Just check out bundled demos that
come with the sdk... Half of Gem could be easily reimplemented using JUCE sdk...
Looks nice, but the window border of JuceDemo is weird. JuceDemo disables the WM-made border, and puts its own border, which doesn't seem to interpret «Maximise» the same way that the WM does, and is perhaps even buggy.
From what I remember JUCE would by default give you pixel-exact UI down to the window border on every platform, at the expense of native-widgets/dialog-boxes/etc. for that specific OS. Well, maybe you can get native widgets if you want, but I don't think you can get native window borders/dialog boxes/etc.
-Jonathan
And what would be the cause of JUCE being slow on some computers ? I don't think that it would be acceptable that JUCE be mysteriously slow on some computers that aren't even old (if that's really what's happening).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-18 à 11:29:00, Jonathan Wilkes a écrit :
From what I remember JUCE would by default give you pixel-exact UI down to the window border on every platform, at the expense of native-widgets/dialog-boxes/etc. for that specific OS. Well, maybe you can get native widgets if you want, but I don't think you can get native window borders/dialog boxes/etc.
Then I don't think that we should be using JUCE. :-/
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-11 à 09:15:00, Jonathan Wilkes a écrit :
Do you still have any of those changes you made to Tk? If so, how do they compare to unpatched Tk when running Hans' array-demo?
Well, yes, I have them, but it's not very relevant, as I already know that those changes make Pd really worse in too many cases.
The interface common to all item-types has a function to return one bbox (bounding-box : x1 y1 x2 y2). It is assumed that the whole bbox has to be redrawn whenever any aspect of the item has changed. For long diagonal lines, this means a damn lot of stuff that isn't even close to the line. I didn't change this.
Then this info is centralised as a single bbox that tells which part of the canvas to redraw. There's only one. In my diff, I replace this by a grid each representing a 8x8 or 32x32 zone, I don't remember what precise size. But that was all, and this caused draw-commands to be duplicated many times the way I did it, because I drew each zone separately with a clipmask. There would have been other ways to reduce the waste, some involving redrawing multiple zones at once in the grid system, and some involving handling multiple bboxes at once and merging them into something that is not a bbox.
I also had other ideas, such as making items modify the grid instead of returning a bbox, which would greatly speed up things like diagonal lines and perhaps pd's arrays (any item in which the bbox has a much greater area than the item).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux. I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ?
Have you tried any Pd-extended 0.43 builds in the past week or two? There have been some key bug fixes recently.
As for trying a .deb without installing, you can extract the .deb and run it in place, something like:
mkdir /tmp/pd-extended dpkg -x pd-extended.deb /tmp/pd-extended cd /tmp/pd-extended/usr/bin ./pd-extended
.hc
On Feb 12, 2012, at 4:03 AM, Billy Stiltner wrote:
When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux. I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ? _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
I added some bug fixes to pdlua a week ago but they haven't appeared in the nightly builds yet. Is sourceforge svn still the right place?
Martin
On 2012-02-12 10:45, Hans-Christoph Steiner wrote:
Have you tried any Pd-extended 0.43 builds in the past week or two? There have been some key bug fixes recently.
As for trying a .deb without installing, you can extract the .deb and run it in place, something like:
mkdir /tmp/pd-extended dpkg -x pd-extended.deb /tmp/pd-extended cd /tmp/pd-extended/usr/bin ./pd-extended
.hc
On Feb 12, 2012, at 4:03 AM, Billy Stiltner wrote:
When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux. I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ? _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yup, still the right place. There was a bug in the svn update script, I just fixed it, so the updates should again automatically be included.
.hc
On Feb 12, 2012, at 11:14 AM, Martin Peach wrote:
I added some bug fixes to pdlua a week ago but they haven't appeared in the nightly builds yet. Is sourceforge svn still the right place?
Martin
On 2012-02-12 10:45, Hans-Christoph Steiner wrote:
Have you tried any Pd-extended 0.43 builds in the past week or two? There have been some key bug fixes recently.
As for trying a .deb without installing, you can extract the .deb and run it in place, something like:
mkdir /tmp/pd-extended dpkg -x pd-extended.deb /tmp/pd-extended cd /tmp/pd-extended/usr/bin ./pd-extended
.hc
On Feb 12, 2012, at 4:03 AM, Billy Stiltner wrote:
When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux. I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ? _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Thanks for the info Hans. Ill try that out. With the version I have now has pd-gui. Where the latest puredata and pd-extende used wish instead. I think the problems were with wish probably because it was jumpin around in the process list like crazy. The pd extended was the latest autobuild, I tried last night. I might have had remnants of another system in place before installing which might have caused some problems. I installed the dev package to compile ggee which seems to be working fine .
On Sun, Feb 12, 2012 at 10:45 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Have you tried any Pd-extended 0.43 builds in the past week or two? There have been some key bug fixes recently.
As for trying a .deb without installing, you can extract the .deb and run it in place, something like:
mkdir /tmp/pd-extended dpkg -x pd-extended.deb /tmp/pd-extended cd /tmp/pd-extended/usr/bin ./pd-extended
.hc
On Feb 12, 2012, at 4:03 AM, Billy Stiltner wrote:
When I tried JUCE on windows it was slow. pretty but slow. Same with
pdlork on linux. I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
If you think that the freezing that you mentioned is a bug in Pd, please file a bug report:
.hc
On Sun, 2012-02-12 at 11:56 -0500, Billy Stiltner wrote:
Thanks for the info Hans. Ill try that out. With the version I have now has pd-gui. Where the latest puredata and pd-extende used wish instead. I think the problems were with wish probably because it was jumpin around in the process list like crazy. The pd extended was the latest autobuild, I tried last night. I might have had remnants of another system in place before installing which might have caused some problems. I installed the dev package to compile ggee which seems to be working fine .
On Sun, Feb 12, 2012 at 10:45 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Have you tried any Pd-extended 0.43 builds in the past week or two? There have been some key bug fixes recently. As for trying a .deb without installing, you can extract the .deb and run it in place, something like: mkdir /tmp/pd-extended dpkg -x pd-extended.deb /tmp/pd-extended cd /tmp/pd-extended/usr/bin ./pd-extended .hc On Feb 12, 2012, at 4:03 AM, Billy Stiltner wrote: > > When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux. I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ? > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ---------------------------------------------------------------------------- "A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
Hans, it could have very well been some lingering installation that didn't get removed before installing. by the way wish was bouncing around I think it might have had something to do with that. I'll try and install again later and see if I can repeat anything, till then I'll just get the dev package and compile the externals I might use. Does Miller's release use pd-gui or wish? What about the releases in sourceforge and autobuild? I haven't tried Miller's release yet.
On Mon, Feb 13, 2012 at 12:19 AM, Hans-Christoph Steiner hans@at.or.atwrote:
If you think that the freezing that you mentioned is a bug in Pd, please file a bug report:
.hc
Both pd-vanilla and pd-extended use both pd-gui and wish. Wish is the Tcl/Tk graphical shell which runs Pd's pd-gui.tcl script to create the GUI.
In Pd versions before 0.43, pd-gui was a binary program written in C which worked with the Wish shell and the pd.tk script.
.hc
On Mon, 2012-02-13 at 00:31 -0500, Billy Stiltner wrote:
Hans, it could have very well been some lingering installation that didn't get removed before installing. by the way wish was bouncing around I think it might have had something to do with that. I'll try and install again later and see if I can repeat anything, till then I'll just get the dev package and compile the externals I might use. Does Miller's release use pd-gui or wish? What about the releases in sourceforge and autobuild? I haven't tried Miller's release yet.
On Mon, Feb 13, 2012 at 12:19 AM, Hans-Christoph Steiner hans@at.or.at wrote:
If you think that the freezing that you mentioned is a bug in Pd, please file a bug report: http://bugs.puredata.info
Thanks for the info Hans.
Has anyone compared performance of something like processing and libpd with the pd gui? I downloaded all the stuff for compiling that and got to the point of making a project in eclipse and got errors with the hello example. With the examples and parts spread across multiple sites bouncing back an forth between them gets very confusing. Seems like JAVA is quicker now than it was 10 years ago but maybe its just the machines are faster.
Has anyone figured out what is the fastest graphics library across all platforms?
I might be able to outline a guideline for drawing a million points in a 100 pixels by 100 pixels when the million points is in shared memory being updated by multiple processes
From: Billy Stiltner billy.stiltner@gmail.com To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at List" pd-list@iem.at Sent: Sunday, February 12, 2012 4:03 AM Subject: Re: [PD] GUI and DSP
When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux.
What was slow with pd-l2ork?
-Jonathan
I tried the latest autobuild of extended as well as the 0.43 vanilla from sourceforge. both installed fine withh Ubuntu software center. they both kept freezing though sometimes it was a toggle tat would freeze it's display or I couldn't get any sound or close dialog after setting audio properties. most of the time stopping and restarting process worked to unfreeze but I had to uninstall them both and put back the version that ubuntu provides. I figured midi start, stop and continue would work with qtractor but it doesn't with any of them so it might bean alsa or qtractor thing. qtractor does sync with jack transpot though. Anywhere I can find extended package deb that doesn't require me to uninstall whats on there ?
I don't remember its been about a year or so since I ran it. Was the same thing that was slow with the other slow versions of pd I guess. Next time Ifire up the machine it's on I'll try to run it. I remember that max with juce on windows would drop out with the x.fm patch if I played a bunch of notes.with a 256b block pd would drop out with polyphony as well but I could run with a 64b block and GEM slinging polygons all over the place but the juce examples were slow. With a lot of overhead. I might not have had enough memory 1GB.
On Sun, Feb 12, 2012 at 1:55 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Billy Stiltner billy.stiltner@gmail.com To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at List" <
pd-list@iem.at>
Sent: Sunday, February 12, 2012 4:03 AM Subject: Re: [PD] GUI and DSP
When I tried JUCE on windows it was slow. pretty but slow. Same with
pdlork on linux.
What was slow with pd-l2ork?
-Jonathan
Make sure you run the most recent version of pdl2ork when you fire it up next.
There have been a lot of speedups since then.
-Jonathan
From: Billy Stiltner billy.stiltner@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-list pd-list@iem.at Sent: Sunday, February 12, 2012 6:30 PM Subject: Re: [PD] GUI and DSP
I don't remember its been about a year or so since I ran it. Was the same thing that was slow with the other slow versions of pd I guess. Next time Ifire up the machine it's on I'll try to run it. I remember that max with juce on windows would drop out with the x.fm patch if I played a bunch of notes.with a 256b block pd would drop out with polyphony as well but I could run with a 64b block and GEM slinging polygons all over the place but the juce examples were slow. With a lot of overhead. I might not have had enough memory 1GB.
On Sun, Feb 12, 2012 at 1:55 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Billy Stiltner billy.stiltner@gmail.com To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at List" pd-list@iem.at Sent: Sunday, February 12, 2012 4:03 AM
Subject: Re: [PD] GUI and DSP
When I tried JUCE on windows it was slow. pretty but slow. Same with pdlork on linux.
What was slow with pd-l2ork?
-Jonathan
Well, yes, I have them, but it's not very relevant, as I already know that those changes make Pd really worse in too many cases.
The interface common to all item-types has a function to return one bbox (bounding-box : x1 y1 x2 y2). It is assumed that the whole bbox has to be redrawn whenever any aspect of the item has changed. For long diagonal lines, this means a damn lot of stuff that isn't even close to the line. I didn't change this.
Then this info is centralised as a single bbox that tells which part of the canvas to redraw. There's only one. In my diff, I replace this by a grid each representing a 8x8 or 32x32 zone, I don't remember what precise size. But that was all, and this caused draw-commands to be duplicated many times the way I did it, because I drew each zone separately with a clipmask. There would have been other ways to reduce the waste, some involving redrawing multiple zones at once in the grid system, and some involving handling multiple bboxes at once and merging them into something that is not a bbox.
I also had other ideas, such as making items modify the grid instead of returning a bbox, which would greatly speed up things like diagonal lines and perhaps pd's arrays (any item in which the bbox has a much greater area than the item).
I think a lot of this would be alleviated for the most part if not entirely if:
pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data)
pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here)
On Feb 12, 2012, at 1:23 PM, Ivica Ico Bukvic wrote:
Well, yes, I have them, but it's not very relevant, as I already know that those changes make Pd really worse in too many cases.
The interface common to all item-types has a function to return one bbox (bounding-box : x1 y1 x2 y2). It is assumed that the whole bbox has to be redrawn whenever any aspect of the item has changed. For long diagonal lines, this means a damn lot of stuff that isn't even close to the line. I didn't change this.
Then this info is centralised as a single bbox that tells which part of the canvas to redraw. There's only one. In my diff, I replace this by a grid each representing a 8x8 or 32x32 zone, I don't remember what precise size. But that was all, and this caused draw-commands to be duplicated many times the way I did it, because I drew each zone separately with a clipmask. There would have been other ways to reduce the waste, some involving redrawing multiple zones at once in the grid system, and some involving handling multiple bboxes at once and merging them into something that is not a bbox.
I also had other ideas, such as making items modify the grid instead of returning a bbox, which would greatly speed up things like diagonal lines and perhaps pd's arrays (any item in which the bbox has a much greater area than the item).
I think a lot of this would be alleviated for the most part if not entirely if:
pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data)
pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here)
I agree. I think a lot of this can be done incrementally. Basically, take a chunk of logic and refactor it so that Tcl/Tk handles the GUI stuff and pd sends pd messages rather than lines of Tcl. One example of where that could be done is the key press/release handling code. Right now, there is a lot of code for this in g_canvas.c. It is possible that the tag/move code could also be done this way.
.hc
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
On 02/12/2012 06:10 PM, Hans-Christoph Steiner wrote:
I think a lot of this would be alleviated for the most part if not entirely if:
pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data)
pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here)
I agree. I think a lot of this can be done incrementally. Basically, take a chunk of logic and refactor it so that Tcl/Tk handles the GUI stuff and pd sends pd messages rather than lines of Tcl. One example of where that could be done is the key press/release handling code. Right now, there is a lot of code for this in g_canvas.c. It is possible that the tag/move code could also be done this way.
.hc
Moving by tag requires a major rewrite on c side of things or reimplementation of widgetbehavior as is the case with pd-l2ork. This is mainly because there are some actions that simply require absolute positioning while others can work through relative positioning (e.g. creating vs. moving). This is why pd-l2ork uses expanded version of widgetbehavior and now is capable (through an iterative improvement) of moving by tag pretty much everything (albeit at the expense of binary compatibility, which IMO is not a problem when pd-l2ork pretty much packages most of additional externals with it and others can be simply recompiled with no changes to the source, with the exception of gridflow that uses unusual approaches to deal with GUI matters).
Le 2012-02-12 à 18:10:00, Hans-Christoph Steiner a écrit :
- pd completely removed redrawing logic from the c code and migrated
it into tcl (which is what you may have done in great part already inside desire-data)
The big problems with (1) is that not only you need to copy all the visible settings of the c object into tcl so that the tcl side has direct access to the info it needs to have, you also to have to sync those things between the two copies. E.g. what happens when you move an object while the patch changes its displayed value, or its background colour ?
- pd used a different toolkit that allowed for more intelligent
addressing of individual gui components (again, JUCE IMO comes at the very top here)
Ok, this needs something like step (1) above, but also note that if you are going to use a GUI toolkit that can't be used from Tcl, you either have to port it to Tcl, or stop depending on Tcl, which itself means either use a Tcl parser written in a language supported by JUCE, or use a different syntax that doesn't refer to Tcl (such as a binary protocol).
I agree. I think a lot of this can be done incrementally.
It's not just that it can : it ought to be incremental. An example of something not done incrementally is DesireData, and see where it did lead.
Basically, take a chunk of logic and refactor it so that Tcl/Tk handles the GUI stuff and pd sends pd messages rather than lines of Tcl.
Sending Pd messages fixes the Tcl dependency problem. You could even run Pd in the server.
But note that client and server could be merged, so that you don't have to serialise and deserialise every thing that the client might need. Then pd-gui would become an extra thread in the server.
More client-server separation is more work, and the amount of sync-work required is greater than what it is in Pd now. I don't know how that compares to the amount of sync-work that would be done by a threaded model.
But basically, there are problems that are fundamental problems, and if you avoid solving things with multithread because mutexes are troublesome, then you'll solve those problems using processes that have to tell each other « ok, done, I'm ready » all of the time and it can grow to similar levels of complexity. For each situation, one or the other might be easier, but it's not very obvious in advance. What's obvious is that people can get into ideologies, and DesireData's design partially had to do with a threads-are-evil ideology.
OTOH, just because the possibility of multi-client pd and remote-client pd are not exploited by many people, doesn't really mean that they're not things worth pursuing... Johannes' multi-client pd involved inserting an extra process between the client and the server so that there can be several clients. Any kind of insertion like that is much harder (or impossible) in a threaded design.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-12 à 13:23:00, Ivica Ico Bukvic a écrit :
- pd completely removed redrawing logic from the c code and migrated it
into tcl (which is what you may have done in great part already inside desire-data)
Yes, that was what I did, plus or minus some big bugs and slowdowns.
- pd used a different toolkit that allowed for more intelligent
addressing of individual gui components (again, JUCE IMO comes at the very top here)
May you state a 2nd and 3rd choice of toolkit ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Feb 11, 2012, at 11:59 AM, Mathieu Bouchard wrote:
Le 2012-02-10 à 20:09:00, Jonathan Wilkes a écrit :
For me the create-delete method uses more CPU but both are pretty intensive. Any Qt devs out there? Or gtk'ers? Maybe a JUCEr? Would those toolkits be able to utilize the GPU? Those would be nice to compare, too.
In the end, switching toolkits wouldn't be a bad idea, but it's not the only solution. Some things inside of tk could be improved. Modifying tk can be scary, more so if we have to think seriously about bundling alpha versions of tk 8.7 together with pd-extended, but the alternative is to rewrite large amounts of code (everything using sys_gui or implicitly referring to Tcl), which is error-prone, hard to test, and too many changes in one chunk.
So, it's not very clear to me which one is best.
I had tried making some changes to Tk 8.5, and it seemed somewhat promising. I was getting large speedups for some cases, and large slowdowns for some other cases. With more work, the latter could have been eliminated. It would benefit most other uses of Tk Canvas in other apps as well, so it could be integrated to Tk itself.
This makes a lot of sense to me. The approach you outline here would also likely be a more rapid path to speeding the Pd GUI up. It can be done incrementally, while switching away from Tcl/Tk has to be done all at once.
Then we can take the pressure off of splitting the GUI stuff out of 'pd' to make sure we get it done right.
.hc
¡El pueblo unido jamás será vencido!
On Feb 8, 2012, at 3:22 PM, Mathieu Bouchard wrote:
Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
While technically correct that's misleading because there's a lot of stuff happening on the 'pd' side that a reasonable person would assume to be handled on the 'pd-gui' side. Well, more than that-- there's stuff happening on the 'pd' side that doesn't need to happen at all, but it can use massive amounts of CPU and consequently a reasonable person gets dropouts when moving an array that has only 100 points visible and erroneously thinks, "Wow, I get dropouts just moving some polygons around on the screen? Tk stinks!"
Besides, you could save some cpu, ram and bandwidth if all those array floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d" when you can use "%x" and similar... especially fixed-width %x such as "%04x".
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
That's an interesting idea, have you tried it? Are you proposing to make all messages between 'pd' and 'pd-gui' binary? Or this would be only for sending chunks of data, like arrays?
.hc
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Le 2012-02-10 à 21:16:00, Hans-Christoph Steiner a écrit :
On Feb 8, 2012, at 3:22 PM, Mathieu Bouchard wrote:
If Tcl had fast base64 support (like Perl/Ruby), the difference would be even bigger. And it would bigger with the ability to send binary data (which can't happen now because "}" counts as end-of-block).
That's an interesting idea, have you tried it? Are you proposing to make all messages between 'pd' and 'pd-gui' binary? Or this would be only for sending chunks of data, like arrays?
That's not what I'm saying, but I could be proposing it, or something similar. Surely it would fix some problems. Much of the thinking came from coding [#see] (which is used all over my patch_dans_patch picture series, and also some other screenshots).
For [#see] I tried base 16 (hex), base 64 (uu or mime), and base 256 (straight «binary»). Apart from braces, a major problem with sending straight binary is byte '\0', which means end-of-string. There's no sys_gui function that accepts sending '\0', which requires passing (size_t n, const char *) instead of just (const char *).
I tried using a 2nd socket just for GF's binary data. To deal with deadlocks due to blocking socket, would have to do a long workaround involving nonblocking sockets.
Then I thought about shared memory (shm, mmap) which is also the fastest possible... in several ways (share with tcl string, or share directly with tk image data).
Finally, the only expedient and most portable way to do things quite fast, was to write a temporary ppm file on the file system and get Tk to read it that way.
IIRC, it's still not GF's default. [#see 1] enables the fast mode. The slow mode grows really slow, and even though there's no [info complete] in the versions of pd that I run, there's something that greatly slows down [#see] as images grow bigger, in a way similar to [info complete], somewhere in t_tkcmd.c or other place.
It doesn't look very possible to send raw binary through pd's tcl socket, the way it's implemented now. It would have to be done the other way that I proposed, in which sys_gui enforces an end-of-packet when returning from certain functions, so that it becomes easy to switch between tcl command mode to binary mode and back, on the same socket. You can't have both on the same socket if you try running [eval], [uplevel] or [info complete] on data that is not even meant to go in such functions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
batinste -
Billy Stiltner -
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jean-Marie Adrien -
Jma/celeonet
-
Jonathan Wilkes -
Martin Peach -
Mathieu Bouchard -
Pierre Massat