Кто-нибудь знает, почему nextEventMatchingMask: tillDate: inMode: dequeue: займет много мс для возврата события?

Question

В игре для OS X это рекомендовалось как способ получения событий клавиатуры и мыши.

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

, который вызывается в основном цикле игры (его кроссплатформенность).

Начиная с самых последних версий OSX 10.5.X этот вызов внезапно занимает много миллисекунд на событие, когда доступно событие, и частота кадров игры изменяется каждый раз, когда событие появляется. Если есть несколько событий, это может занять до 10 мс на кадр на более медленном Mac.

Кто-нибудь знает, почему это так? Или что я могу сделать, чтобы получать события, не оказывая сильного влияния на игру?

Я пытался управлять событиями мыши сам, получая положение мыши вручную и когда она приближается к краю экрана, деформируя его к центру, но это вызывает заминку в движении (конечно, только когда курсор скрыт ).

Другими альтернативами может быть получение информации от менеджера HID, что мы уже делаем для джойстиков, но HID не совсем понятен.

Чем быстрее Mac, тем больше заметны эти проблемы с получением событий.

Answer 1

Я думаю, вам нужно освободить и перераспределить пул авто-релиза внутри вашего цикла: поскольку у вас есть цикл, все автоматически выпущенные элементы просто накапливаются и никогда не сбрасываются.

Answer 2

Я думаю, что вы должны использовать фактическое значение в аргументе untilDate, например [NSDate distantFuture] или [NSDate distantPast]. Функция будет блокироваться до тех пор, пока событие не станет доступным в первом случае, а сразу же вернется с событием nil во втором случае.

Я узнал об этом из GLFW исходного кода.

Answer 3

Случайно, я не знаю, почему метод занимает так много времени, чтобы вернуться. Это стоит исследовать в списке cocoa-dev или на другом форуме Apple. Я предполагаю, что управлять событиями самостоятельно - плохая идея - AppKit оптимизирован для этого, и вы можете смело утверждать, что он будет намного быстрее, чем составной пользовательский код.

Однако есть что-то, что вы можете сделать, чтобы это не повлияло на вашу игру: поместите это в отдельную ветку. Это рекомендуемый подход, чтобы предотвратить зависание пользовательского интерфейса во время длительного вызова метода. Apple опубликовала Введение в руководство по программированию Threading , которое поможет вам освоиться с критическими концепциями, которые вам понадобятся.