This is definitely useful. It would be great if you could the builds
between 2007-11-04 and 2007-11-09 to narrow it further. I checked in
a few things in that time period.
.hc
On Nov 12, 2007, at 8:49 PM, simon wise wrote:
Hans
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.
simon
Pd-0.40.3-extended-20071104 61.935 27.534 27,507 closed pd then reopened: 28.551 27.44
Pd-0.40.3-extended-20071109 53.346 28.093 28.555 28.333
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 patchesi'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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith