[PD] GUI speed

[Pedro Lopes]

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 at gmail.com>

>
>
> On Tue, Sep 28, 2010 at 6:12 PM, Mathieu Bouchard <matju at artengine.ca>wrote:
>
>> 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
Pedro Lopes (ongoing MSc)
contact: pedro.lopes at ist.utl.pt
website: http://web.ist.utl.pt/Pedro.Lopes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100928/2dccdd02/attachment.htm>