>________________________________
>From: João Pais <[email protected]>
>To: András Murányi <[email protected]>; pd-list <[email protected]>; Jonathan
>Wilkes <[email protected]>
>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.
>
>
>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
