Hi everyone, Thankyou all for your replies. Plenty of food for thought there - much appreciated. Looks like timers and flow control is the way forward then, if I want to tackle this. I just thought I'd see if there was anything built in to the standard UI frameworks that might be able to help, but it seems not.
To answer one of Quincey's comments: >> The low priority thing only really runs when *nothing* else at all is >> happening. > > This shouldn’t be happening, on most Macs. An average desktop Mac has at > least 2 CPU cores (4 logical CPUs), which should allow at least 2 > compute-bound tasks to proceed simultaneously... The reason for this is that the coalescing, post-when-idle NSNotifications I was talking about were being posted to the main queue. Hence all the main queue time was being taken up in ultra-smooth drawing of sliders etc, since that of course also happens on the main queue (UI drawing...). I agree that it looks as if I should bite the bullet and run all this stuff multithreaded. The thing is, a lot of it doesn't fundamentally ~need~ to run multithreaded - one thread should be enough to get drawing responsiveness that I'm pretty happy with, if I could just find a way to control what priorities the different aspects are being treated with. Sounds like timers, flow control and/or multiple threads/queues is the way to go if I want to solve this properly. Cheers Jonny. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
