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