I did a little test to figure out why updating the pd gui causes so much CPU activity on OSX. The test consists of four groups of metro, random, and some number boxes placed around the patcher window. To run the test, you need to run the patch and a little app called Quartz Debug, which is part of the Developer Tools (it's in /Developer/Applications/). This fantastic tool shows which parts of the screen are updated by flashing the area as a colored box.

In the Quartz Debug window, check the box next to 'Flash identical updates' for this test. Open the patch and start the first number box in the upper left spinning - you will see the number box flashing red as it updates. Now stop that one and go to the middle set of objects and start the metro - notice that there is a red rectangle connecting the two number boxes as they update. Next go to the objects in the upper right and repeat the test - don't do this if you are epileptic!! At this point, you might be thinking, it's the patch cord connecting them that's the problem. Well start the metro in the top left and the bottom right and witness the wrath of Quartz Debug! Run the tests again with top open and see how much CPU is being drained.

Ok what does the red box and the test really mean? It shows that there is a huge amount of wasted cycles updating part of the gui that doesn't need updating. I don't really know where this inefficiency comes from - it could be tcl/tk* or the way pd uses tcl/tk or ???. Maybe someone with more knowledge can have a look into this, and figure out what's going on, or at least give me a hint where to look.

*My suspicion is that it's tcl/tk at fault here. Incidentally, the WishShell spends most of it's time converting RGB pixels to ARGB while the huge red rects are being updated. Seems truly wasteful.

cgc