Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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 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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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 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@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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
On 9 Nov 2007, at 2:59 AM, Steffen Juul wrote: I made a patch to test the behavior. This is the test: 1) Note that the patch is 500x300 initially. Either by opening in a text editor or with 'head -1' or. 2) Open the attached patch. Click the [10( on one of the sides. 3) Note that the patch has grown to 504x304 Now the weird bit. 4) with out closing the patch, click the [10( again. 5) Note that it has _not_ grown to 508x308. 6) Close the patch 7) Reopen the patch 8) Click the [bang( 9) Note that it has now grown to 508x308 So it seams it grows 4px per run with a reload. This growing on each save/open cycle seems to have changed in the latest autobuilds: Pd-0.40.3-extended-20071109 for PPC (on OSX 10.4.8) Now I get a 2 pixel SHRINKING of the window on each of these cycles, and the part of the patch shown when the window opens isn't exactly the top left part anymore. IIRC the 3 pixel border around the active window has just been removed - that could account for the 6 pixel difference in the shrinkage/growth ... maybe if the border was made 1 pixel the size of the window would be stable Playing around and testing it seems something (possibly in the new visuals) is slowwwing down displaying/opening patches - resizing a window is jerky and CPU hits 100% (same patches have no problems resizing, with much lower CPU usage, in autobuild Pd-0.40.2- extended-2007-05-01 on the same system) which will have consequences (dropouts etc) and is extremely noticeable on my ageing powerbook - it seems to depend on how many objects are visible in the window at the time (when only a small part of a big patch is showing the problem is less). Large patches take an age to open. The new visuals are nice - I'll find out soon how much it helps my problems swapping patches with intricate layouts and GOP between mac, linux and windows (certainly old patches for mac layout cleanly, no overlaps etc). The live update for the font bomb is great. Thanks for all the hard work, especially the documentation ... lots of nice touches ... the improved help menu works well, the web references will great for newcomers finding their way around and make the locations for web documentation more consistent (are there local settings needed for the IRC item to work?) ... now midi and Gem help work properly! ... the [pddplink] GUI deserves a place in the 'put' menu! (I guess its been around for a while but I've only just noticed it) ... the 'text window' checkbox is good - does it save cpu if it is off, eg does it mean [print] uses less cpu? ... the cursor changing in click-able areas is nice, and I'm sure I'll find a use for [cursor] in setting up nicer user interfaces. simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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 -- pd-0.40.3-extended-20071106 mac osx 10.4.8, 15 G4 PB 1.67 GHz, 1 GB ram ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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. simon ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
On 09/11/2007, at 7.41, Hans-Christoph Steiner wrote: This is a very helpful illustration of the bug. I think that it's probably happening when opening the patch. That sounds reasonable. Maybe your new cursor position object can help answer that question. Could you add this info to the bug tracker, I believe there is already a bug report for this one, and I'll try to look at it tomororw. I submitted a new report, since i couldn't find a matching report already (despite people claims it's been there for ages). ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Growing patch-window size (Was:Re: changing the look of Pd to be more readable)
On 07/11/2007, at 19.07, marius schebella wrote: you can start searching in 2002. Now i don't know if i repeat anyone from the past. I apologize beforehand. Hans-Christoph Steiner wrote: If there isn't a bug report for this, please file one and I'll take a look when I get a chance. Maybe we can keep it on list for a few bits more. I made a patch to test the behavior. This is the test: 1) Note that the patch is 500x300 initially. Either by opening in a text editor or with 'head -1' or. 2) Open the attached patch. Click the [10( on one of the sides. 3) Note that the patch has grown to 504x304 Now the weird bit. 4) with out closing the patch, click the [10( again. 5) Note that it has _not_ grown to 508x308. 6) Close the patch 7) Reopen the patch 8) Click the [bang( 9) Note that it has now grown to 508x308 So it seams it grows 4px per run with a reload. More weirdness. Or observations. 10) Now try the above but clicking the [100( on either side. 11) Note that it still only increases by 4px. 12) Close and reopen the patch. 13) Just save it as you normally would. 14) Note that only one save increases the size 4px. 15) Note that using either the [until] method or the [delay] method doesn't make a difference. grow.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
