From: João Pais jmmmpais@googlemail.com To: András Murányi muranyia@gmail.com; pd-list pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Sent: Friday, August 26, 2011 5:19 PM Subject: Re: [PD] [PD-dev] tkwidgets
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?
We should separate poor tcl/tk performance from, well... I don't exactly know what to call this:
A "Put" menu array with default settings has:
a text item for a label
a line item in the shape of a rectangle for the border (why not a rectangle?)
a rectangle item for each element of the array that can fit visibly inside the graph (why not lines?)
Anyway, if the width of the graph in pixels is greater than the number of elements, the rectangles are elongated to fill the space in between. These are the "steps" you get when filling a 100 pixel wide graph with an array of 10 elements.
If the width of the graph in pixels is less than the number of elements, then one rectangle stands in for multiple array elements. Thus for a 10 pixel-wide graph holding a 100 element array, you get 10 elements per pixel.
So far so good.
Now, starting with a "Put" menu array with a graph only 10 pixels wide, increase the size of the array while keeping the graph width constant.
At size 10000 or even 100000 it may look like tcl/tk is getting sluggish, but if you use the tcl prompt you can confirm that tk indeed keeps a constant number of rectangle items-- in this case, 10-- on the canvas regardless of the # of elements in the array. (Granted it's deleting and re-creating instead of just moving the thing, but let's set that aside for the moment.) What's going on here?
Once you get up to about 10 million elements, you can see a symptom of the problem-- pd is sequentially sending messages for each rectangle item, and in debug mode the latency between each message arriving at the gui side is quite noticeable. Obviously there must be some calculation on the C side of things that involves every element represented by that rectangle. So if you have a 10 pixel-wide graph and 10 million elements, that would mean Pd is doing some calculation that involves 1 million elements PER ARRAY RECTANGLE. And this happens for _every_ pixel you happen to be moving the graph! You can't blame tcl/tk for this-- it's moving those rectangle items as fast as it receives them from Pd.
This is all to say: choose any toolkit you want, but unless it has a (non-buggy) time travel widget, there's no way it's going to move that 10 million-element array faster than pd can finishing playing a million games of tic-tac-toe*, or whatever it's doing between each "$canvas rectangle create etc." message that it's sending.
-Jonathan
- Maybe the solution is to make Gridflow part of Pd vanilla, so we can use it to play tic-tac-toe-between-array-rectangles more efficiently. :)
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.