Я понял это некоторое время назад, и проблема заключалась в том, что при прокрутке я выполнял много необычных манипуляций с представлениями, например, как на iPhone UITableView добавляет и удаляет представления, когда они прокручиваются на экране и за его пределами. Это отлично работало для производительности - но чем больше я увлекался программированием на OSX, тем больше понимал, что это неправильно для OSX (но правильная идея iPhone).
В любом случае, на самом деле, похоже, что когда вы делаете что-то вроде прокрутки колеса, событие прокрутки отправляется в представление, находящееся под курсором мыши, а затем оно сбрасывает респондеры / представления, пока оно не достигнет чего-то это справляется. Обычно это не проблема, но с прокруткой импульса ОС на самом деле просто отправляет все меньшие события scrollWheel в представление, которое находилось под курсором в момент начала импульса . Это означает, что если представление удаляется во время прокрутки (потому что оно прокручивается за пределами экрана или чего-то еще), оно разрывает цепочку и импульс останавливается, потому что представление, которое все еще получает сообщения scrollWheel, больше не находится в иерархии представления.
«Простое» исправление состоит в том, чтобы не удалять представление, получившее последнее событие scrollWheel, даже если оно не на экране. Лучшее решение (и тот, с которым я пошел) состоит в том, чтобы не пытаться использовать NSViews, как будто они являются UIViews, а вместо этого просто рисовать контент, используя drawRect. :) Мало того, что он примерно в миллиард раз быстрее, он просто работает (tm) с прокруткой импульса, потому что именно так OSX ожидает, что что-то будет сделано.
Повторяйте за мной: OSX - это не iPhoneOS ..: P