That has little to do with Tcl/Tk being slow. That has a lot more to
do with how Pd is implemented. It generates and sends raw Tcl to the
GUI, and if you are moving a lot of stuff, that means a lot of raw Tcl
needs to be generated, sent, parsed, and executed. That definitely
slows things down. In my tests, I saw that moving a big patch around
or animating a big array could send 1 megabyte of raw Tcl to the GUI
per second. Receiving, parsing, and executing 1 megabyte of code per
second is actually pretty good, IMHO.
What needs to happen is that Pd should call Tcl procs not send blocks
of raw Tcl.
.hc
On Aug 26, 2011, at 5:19 PM, João Pais wrote:
tcl/tk behaves very slowly for fast calls, such as when dragging an
array of considerable size, or a big group of objects? afaik this is
something that could be improved in the present platform, but how
better could it be when using another gui framework?
It might be a good idea to list the problems with tcl/tk so we can
weigh them against the difficulty of using a different GUI
toolkit. The problems I see are:
* difficult to implement a decent zoom function for a canvas
* can't display png without the Img library (included in 8.6)
* can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it
means that (without prior planning) it's hard to take a patch
you've been working on at font size 10 and display it adequately
over a projector, for example. (If there's a work around I'd like
to know it.)
I'd like to hear others, but I'm mostly interested in problems with
tcl/tk >= 8.5 as the GUI.
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
----------------------------------------------------------------------------
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
