Почему в OS X нет тех же проблем с мерцанием, что и в Windows?

И Windows Vista/7, и OSX используют механизмы компоновки для рисования растровых растровых изображений на экране. Эти механизмы композитинга отвечают за обработку вывода из всех окон и отрисовку конечного изображения на экране. Этот подход к композитингу заключается в том, как OSX может использовать эффект джинна при сворачивании до док-станции и как aero рисует полупрозрачные границы. Они также предотвращают мерцание, как будто растровое изображение для заполнения определенной области экрана недоступно, оно будет использовать уже имеющееся изображение, а не рисовать пустую область.

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

Поскольку композитер Windows был добавлен только в Windows Vista и только тогда, когда был доступен графический процессор и у вас была правильная версия ОС, он не так распространен, как Quartz Composer в OSX. Поскольку компоновщик не всегда используется в Windows, мерцание будет происходить, когда область пуста, и приложение, ответственное за рисование, не может перерисовать область достаточно быстро.

Mac OS X имеет окна с двойной буферизацией.

Вам не нужно ничего делать, чтобы это произошло. Это за кадром.

Вы (почти всегда) не рисуете явно окно в Cocoa, когда что-то меняется, вы делаете недействительной область окна. Фреймворк позже будет спускаться по иерархии представлений и отрисовывать грязные области окна во вторичный буфер. Затем он меняет местами буферы.

При желании вы можете сделать некоторые обещания, которые позволят фреймворку использовать ярлыки при перерисовке, но все они не являются обязательными. Только здравомыслящие взгляды затронуты.

Если ваш подкласс NSView реализует метод isOpaque для возврата YES, то фреймворк никогда не очистит что-либо за вашим представлением и не отрисует под ним какие-либо представления.

Реализация preservesContentDuringLiveResize для возврата YES дает вам некоторые дополнительные обязанности, но может повысить производительность при изменении размера окна.

В версии 10.6 добавлены еще два новых API такого типа, layerContentsRedrawPolicy и layerContentsPlacement.

Наконец, пользовательское рисование менее распространено, чем в Windows. Большинство представлений, которые вы видите, предоставляются фреймворком и не являются подклассами. Предоставленный фреймворком означает оптимизированный Apple.

Да, это все автоматически двойная буферизация. Конечно, если вы используете устаревший код из Mac OS 9 или код, перенесенный из Windoze, это означает, что вы, вероятно, используете тройную буферизацию, не зная об этом. Эй, велосипеды дешевые!