Sorry to meddle:
-> Its not "drawing a number" its updating a GUI at a desired speed. Data flows at enormous speeds, GUIs do not, either Tcl or others. When you ask an update on an array, GUI box, etc... that's a lot of stuff happening. But yes, our computers in 2010 are fast as hell. Tcl is an amazing platform, I'm not in need of a faster PD or better GUI but praise all efforts in that direction., just wanted to point out that the GUI of pd is much more than "updating number boxes".
Overall, re-writing the GUI entirely without tcl (aka changing GUI platform) is scary and massive. It would be nice, but its a long long road. At the moment if pd's native GUI does not satisfy me I bind it with another, as3, processing, etc... its not fast (well localhost networking is stupidly fast), but sure is pretty.
Best regards, Pedro
p.s.: interesting exercise for those that wanna see how much time your cpu wastes with gui in pd is running a patch without gui. I had a project that used my DTW in pd and a long patch (for my standards) and when we ran it for the first time without gui... wow. Somethings went faster than expected and some didn't work because it was all too fast :) A bit of cleaning solved it, but its an interesting test for non-visual patches.
2010/9/28 András Murányi muranyia@gmail.com
On Tue, Sep 28, 2010 at 6:12 PM, Mathieu Bouchard matju@artengine.cawrote:
On Tue, 28 Sep 2010, Mathieu Bouchard wrote:
On Tue, 28 Sep 2010, Bernardo Barros wrote:
Is there already some benchmarks of the new puredata gui? Would be nice to have it.
It's nowhere close to being a rewrite : essentially, all of the code that you would benchmark has almost not changed since Pd 42.
I mean it hasn't changed much since way before that time : afair, Pd 38 was the last time there was a speed improvement, and it was due to the addition of sys_queuegui. There were a number of bugfixes and other changes not related to speed.
Much of the speed improvement that can be made, can only be made by modifying Tk's source code itself (or switching to a different renderer).
...and/or, as far as i understood, reinventing pd in a way that the GUI doesn't chat with the core about gui elements and their properties, but the core is limited to audio and other "abstract" calculations and it's the GUI which takes care of everything that happens on the GUI. I'm not sure if i understood this right, and i suspect that it's a tremendous work, and i also suspect that it may involve externals to be rewritten, but i have a feeling that Tcl/Tk is not that slow by itself but the bottleneck is GUI<->core communication. C'mon, drawing a number with a big font threatens the CPU? On the computers we have, in 2010? I can't believe that.
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list