And a good thought it was 
- but alas, the CPU load is somewhere between 200% and 250% with J-1.38 compared to J-1.21.
Some additional info on the subject:
After optimisations, the CPU load before and after the Juce switch is now comparable (differs by < 5% actually in favor of Juce 1.38 ). The new Juce window is still incredibly sluggish to move around - sluggishness directly proportional to CPU load. Even when less CPU time is available for old Juce, it has no perceivable impact on response when moving windows around.
I know I am just stressing and pushing my point, but if anyone plans to do something about this, as much info as possible is needed. For example - as earlier suggested, the timing of redraw is probably not the issue, since the sluggishness is proportional to CPU load. The only reason for this I can think of, is if scheduling is done with very low priority, which seems kind of far fetched?
-A
So is it just that itās actually repainting the window each time it moves, when in the old version it didnāt do that?
Hi again, sorry the lateness - I havenāt seen your reply Jules.
The old Juce-version did just as many repaints I think. Itās just the overhead of painting stuff that is much slower in the newer versions. Through profiling, I got the impression, that the callstack is much deeper in the new versions when painting.
The optimizations local to my project only takes care of my own overhead - and eliminates a lot of paint calls (and thus avoids new-version-overhead) 
-A
Yes, Iād expect the callstack to be deeper, because itās now repainted via the HIView layer, which will be deeply nested inside Appleās windowing code.
Yes, those are precisely the calls. So - either these calls are particularly heavy on the PPC, or there are just too many of them, for the slower PPCs to keep up.
- This is why I wish for an easy switch between the two schemes of painting. I realize this is cumbersome, and obsolete in a couple of years, butā¦
-A
Indeed moving around a Juce application window on my iBook G4 is really slow whereas other applications move very fast on the screen of my G4. I never have tried previous Juce versions, but it would be nice if moving the window was faster.
When I move a Juce window around very quickly CPU usage goes up to 100%, whereas if I move a Mac regular application, CPU only goes up to 40-50% (and the window still moves fast!).
On my Windows computer it is a bit different: Although moving a Juce window is acceptable, but still sluggish compared to moving a normal Windows app window, the Juce app only consumes 35% whereas the Windows app consumes 100%.