On Mar 22, 2015, at 16:28 , Graham Cox <graham....@bigpond.com> wrote: > > Each cycle of the loop it looks at whether any state of any "device" has > changed and propagates the change.
What I don’t understand is what this has got to do with run loops at all. You want to poll some state often, I suppose you can do it with run loops, but seems clunky if you have to *force* the run loop to cycle often. The thing that comes to mind as an alternative is CVDisplayLink. It’s effectively a low-overhead timer that runs at the display update rate (generally 60 fps, synchronized with display updates, as a matter of fact). I understand that in the case the rate isn’t important — though you don’t need anything higher than that, because you can’t update the UI at a faster rate anyway, when something changes in your simulation — but it’s probably high enough. Of course, you’d need to keep the processing in your display link callback to a minimum, and anything that triggers a lot of work or needs to update the UI will need to be packaged into a block that’s shunted off to a background thread or the main thread. But it’s a fairly simple way to do high-frequency polling that’s responsive but not real-time-critical. _______________________________________________ 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
