Can't agree with you on that. If a graphics operation takes a long time under a layers lock and is being performed on the input.device's context, this is what you'll get as well. Imagine doing a large, complex cpu draw leading to loads of accesses to chip ram - ouch.
The problem is certainly that it's being done on the input device's context, rather than in the application proper. That at least explains why the UI is bogged down... input devices would be running at the same priority as Intuition... which is why you'd never want to do something that expensive this way.
Doesn't explain the audio glitching... that should be at a higher priority. Audio needs to be realtime, web browser overhead, not so much. I guess you have to know the code... maybe there's a good reason. It's just fairly shocking to see a MacOS display outperform... well... much of anything.