[PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)

[Hans-Christoph Steiner]

On Nov 11, 2007, at 9:18 PM, simon wise wrote:

>
> On 12 Nov 2007, at 10:02 AM, Hans-Christoph Steiner wrote:
>
>>> simon wise wrote:
>>>
>>>> Playing around and testing it seems something (possibly in the new
>>>> visuals) is slowwwing down displaying/opening patches
>>>
>>> i've noticed the same.
>>> cheers, robbert
>>>
>>> --  pd-0.40.3-extended-20071106
>>> mac osx 10.4.8, 15" G4 PB 1.67 GHz, 1 GB ram
>>
>> The changes that I made to enable the different colors are really
>> quite trivial so I have a hard time believing that to be the
>> culprit.  But there have been quite a few changes since 2007-05-01.
>> Maybe try an autobuild from a month ago, before the color changes?
>>
>> Could you post patches that illustrate the slow loading?
>
> I'll try earlier versions to see when the problem happened - but it  
> is true of ALL patches - whenever they are redrawn it takes extra  
> CPU time by the Pd-0.40.3-extended process. I'll keep  
> exploring   ... but so far:
>
> CPU peaks when a patch is opened, the window is resized or moved  
> onto the screen (the CPU usage depends on the number of elements  
> currently visible in the patch window).
>
> CPU is not affected when windows are moved inside the screen  
> boundaries or covered/uncovered by other windows, dialogue boxes etc.

This is nothing new, Pd uses Tcl/Tk inefficiently (for example,  
creating and destroying graphics instead of using the tk "move"  
command).  So the question is, is it worse with the filled in boxes,  
which use "create polygon" instead of "create line"?

Also it would be good to compare to pd-vanilla 0.40-2.  It should be  
possible to time the opening of a patch using [realtime], having real  
numbers would be quite useful.

.hc


------------------------------------------------------------------------ 
----

All information should be free.  - the hacker ethic