iOS: почему переопределение drawRect прибегает к программному рендерингу?
Я не большой поклонник графических API-интерфейсов iOS и их документации и уже некоторое время пытаюсь сформировать высокоуровневое представление и структуру процесса рендеринга, но имею только кусочки информации. По сути, я пытаюсь понять (опять же, на высоком уровне);
1) Роль API-интерфейсов Coregraphics и CoreAnimation в конвейере рендеринга на всем пути от CGContext до буфера переднего кадра.
2) И на этом пути (это было наиболее запутанным и наименее разработанным в документации), какие задачи выполняются процессором и графическим процессором.
Я надеюсь, что после выхода Swift и Metal API-интерфейсы будут пересмотрены.
2 ответа
1) Роль API-интерфейсов Coregraphics и CoreAnimation в конвейере рендеринга на всем пути от CGContext до буфера переднего кадра.
Core Graphics - это библиотека чертежей, которая реализует те же примитивы, что и PDF или PostScript. Таким образом, вы кормите его растровыми изображениями и различными типами пути, и он производит пиксели.
Core Animation - это композитор. Он создает экранное изображение путем компоновки буферов (известных как слои) из видеопамяти. Во время компоновки может применяться преобразование, перемещение, вращение, добавление перспективы или выполнение чего-то еще для каждого слоя. Он также имеет подсистему временной синхронизации, которая может выполнять временные корректировки любой части этого преобразования без дополнительного программного вмешательства.
UIKit связывает вещи так, что вы используете CoreGraphics, чтобы рисовать содержимое вашего представления в слой всякий раз, когда меняется само содержимое. В первую очередь это касается процессора. Для таких вещей, как анимация и переходы, вы обычно применяете или планируете корректировки композитинга. Так что в первую очередь это касается ГПУ.
2) И на этом пути (это было наиболее запутанным и наименее разработанным в документации), какие задачи выполняются процессором и графическим процессором.
Отдельный слой рисования: CPU
Преобразование и компоновка слоев для построения дисплея: графический процессор
iOS: почему переопределение drawRect прибегает к программному рендерингу?
Это ни к чему не "прибегает". Точно такой же конвейер применяется независимо от того, написали ли вы соответствующие drawRect: или Apple, сделал.
Я надеюсь, что после выхода Swift и Metal API-интерфейсы будут пересмотрены.
Swift и Metal полностью ортогональны к этому вопросу. API-интерфейсы очень хорошо сформированы и пользуются большим уважением. Ваши проблемы с ними - как вы свободно признаете - отсутствие понимания. Нет необходимости пересматривать их, и Apple не дала никаких указаний на то, что это произойдет.
Вы начали с видео WWDC? Они широко охватывают многие детали. Например, улучшенная графика и анимация для приложений для iOS в этом году является хорошей отправной точкой. Разговоры о базовом образе, как правило, также полезны (я еще не смотрел этот год). Я настоятельно рекомендую вернуться к прошлым годам. Они провели отличные дискуссии о конвейере CPU/GPU в предыдущие годы. Основные методы WWDC 2012 были очень полезны. И, конечно, обучение эффективному использованию инструментов так же важно, как и понимание реализаций.
Apple обычно не предоставляет подробные сведения о реализации низкого уровня в основной документации. Детали реализации не являются интерфейсными обещаниями, и Apple время от времени меняет их, чтобы повысить производительность для большинства приложений. Иногда это может привести к снижению производительности в угловых случаях, что является одной из причин, по которой вам следует избегать хитрости с приемами повышения производительности.
Но видео WWDC содержат именно то, что вы описываете, и проведут вас через конвейер рендеринга и как его оптимизировать. Рекомендации, которые они дают, имеют тенденцию быть очень стабильными от выпуска к выпуску и от устройства к устройству.