> On 21 Aug 2016, at 3:59 AM, Andreas Falkenhahn <andr...@falkenhahn.com> wrote: > > Longer story: > > Yes, I know, my app isn't doing things the Cocoa way but that's not possible > because it's a multi-platform app written in C and I need to make the Cocoa > backend > fit into this fixed, abstracted multi-platform design. Hence, in my > NSApplicationDelegate's > "didFinishLaunching" I'm immediately doing a [NSApp stop:nil] and I'm then > processing > events manually using an old-school model of waitEvent() and handleEvents(). > Unfortunately, the OS-independent backend calls handleEvents() really, really > often so I need a throttle to avoid killing performance of my app. The timer > throttling event loop execution to 100 times per second plus > GetNumEventsInQueue() > worked like a charm on Carbon. But now I'd need a Cocoa equivalent for > GetNumEventsInQueue()...
Is it not possible to adapt this model to invoking [NSApp nextEventMatchingMask:untilDate:inMode:dequeue]? This method will sleep until there’s an event to handle, so the caller can’t force it to go any faster than it needs to go naturally. Even if the generic model code calls WaitEvent in a tight loop, if WaitEvent calls down to this, you aren’t really polling. Even better would be to break that loop into a NSRunLoop, but it may not be possible, depending on the design of the code. If your code is truly polling without sleeping, it’s going to be a horrible citizen in terms of battery life and CPU hogging. It might even be worse than the iOS Facebook app, which is hard to believe ;-) —Graham _______________________________________________ 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
