Thanks again for your replies. I tried your various suggestions and they did not directly solve the problem, but trying them out gave me a lot more clues to help understand what was going wrong. It was in fact your mention of setNeedsDisplay that prompted me to look at the actual low-priority drawing code that I was using. The underlying problem turned out to be in some old drawing code that I wrote when I was first learning cocoa and had not touched since! It had not even occurred to me that that could be at the root of the problem.
I was locking and unlocking around a call to [NSImageView setImage], which I am pretty certain is unnecessary. This was presumably more than just inefficient - I suspect it was causing a bottleneck in the GUI update code when the code blocked on the "lock" call, and because this code was blocked there genuinely *were* spare CPU cycles available. It may be for this reason that many of the deprioritizing strategies I tried weren't very effective (possibly combined with the issues you were describing with exactly how the scheduler works). So anyway, it may not come as a huge surprise to you that the underlying problem turned out to involve some code that I had NOT mentioned in my original email! It's great to have got to the bottom of the problem, anyway! Jonny_______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
