Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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
On Nov 11, 2007, at 2:19 PM, robbert van hulzen 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?
.hc
¡El pueblo unido jamás será vencido!
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 ramThe 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.
simon
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
simon
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.
On 13 Nov 2007, at 2:59 AM, Hans-Christoph Steiner wrote:
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. :)
indeed!
the problem first occurred in the 07/11/06 build (there must have
been a few changes as the .app is 20MB larger), all is as it should
be in 07/11/04
I'll try timing etc now
simon
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
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
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
-
Hans-Christoph Steiner -
robbert van hulzen -
simon wise