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

simon wise simonxwise at hotmail.com
Tue Nov 13 02:49:10 CET 2007


using your speedtest on my machine for the versions shows little  
difference in the times measured (old Powerbook G4 667MHz OSX10.4.8).

time to display the patch is much longer than the measured times - a  
couple of seconds at least in the newer autobuild - and CPU reads  
high for most of that time.

I added an [osc~] to test the effect on audio - there are of course  
dropouts during opening and closing on each build, but the redrawing  
the window in the newer build gets much worse with audio on, for  
example resizing the window can take several seconds. The audio does  
not drop out during this redraw.

A very interesting difference between the two builds is:
- in the older build with audio on I can see the drawing process (no  
dropouts) - when the window gets smaller there is no visible redraw  
and no delay, if the window gets larger the new area is imediatly  
drawn in white but remans white for a while before being filled in,  
there seems no change to the area already drawn
- in the new build the whole window is redrawn with any change in  
window render area, with much longer waiting times when the window  
shows many objects even if none of them change or only a small change  
is made. When the window is made smaller the whole visible area  
appears to be redrawn. There are still no audio dropouts but now the  
window border takes some seconds to update (unlike the older build  
where the border is drawn quickly but the details a drawn later).

I hope this may give some clues as to where the problem is.


closed pd then reopened:


On 13 Nov 2007, at 2:59 AM, Hans-Christoph Steiner wrote:

> On Nov 11, 2007, at 11:12 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.
>> another odd, unhelpful behaviour and possibly a useful detail:
>> when a GOP abstraction is open while editing (ie it is showing as a
>> grey rectangle) and the grey rectangle is moved then CPU usage goes
>> up and the abstraction's window in the background is (very
>> redundantly) redrawn
> I made no changes there.  You are beginning to discover for yourself
> the inspiration behind Desire Data. :)
> .hc
> ---------------------------------------------------------------------- 
> --
> ----
> I have the audacity to believe that peoples everywhere can have three
> meals a day for their bodies, education and culture for their minds,
> and dignity, equality and freedom for their spirits.      - Martin
> Luther King, Jr.
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list

More information about the Pd-list mailing list