Anyone know why nextEventMatchingMask:untilDate:inMode:dequeue: take many ms to return an event?

Question

In a OS X game calling this was recommended as the way to get keyboard and mouse events.

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
for(;;)
{
    NSEvent* event = [NSApp nextEventMatchingMask:NSAnyEventMask untilDate:nil inMode:NSDefaultRunLoopMode dequeue:YES];
    if(!event) break;
    processevent(event);
    ...
}
[pool release];

which is called in the games main loop (its cross platform).

Since the most recent versions of OSX 10.5.X this call is suddenly taking many milliseconds per event when there is an event available, and the game' frame rate is affected any time an event appears. If there are multiple events it can take as long as 10ms per frame on a slower mac.

Anyone have a clue as to why this is? Or what I can do alternatively to get events without impacting the game so much?

I tried managing the mouse events myself by getting the mouse position manually and when it gets close to the edge of the screen warping it to the center, but that causes a hitch in the motion (only when the cursor is hidden of course).

Other alternatives might be getting stuff from the HID manager,which we already do for joysticks, but HID is not terribly clear.

The faster the mac the more these hitches from getting events are noticeable.

Answer 1

Offhand, I don't know why the method is taking so long to return. That's worth investigating on the cocoa-dev list or another Apple forum resource. My guess is that managing the events yourself is a bad idea — AppKit is optimized for that, and you can safely bet it will be a lot faster than thrown-together custom code.

However, there is something you can do to keep it from affecting your game: put it in a separate thread. This is a suggested approach to keep your UI from freezing up during a long method call. Apple has published an Introduction to Threading programming guide that can help you get up to speed with the critical concepts you'd need.