Как напрямую обновлять пиксели - с помощью CGImage и прямого CGDataProvider

Актуальный вопрос

Несколько ответов решат мою проблему:

1. Могу ли я заставить CGImage перезагружать свои данные из прямого поставщика данных (созданного с помощью CGDataProviderCreateDirect), как это делает CGContextDrawImage? Или есть другой способ настроить self.layer.contents для этого?
2. Есть ли CGContext конфигурация или трюк, который я могу использовать для рендеринга изображений 1024x768 со скоростью не менее 30 кадров в секунду, согласованно с CGContextDrawImage.
3. Кто-нибудь смог успешно использовать CVOpenGLESTextureCacheCreateTextureFromImage для обновления буфера в реальном времени с собственными данными текстуры? Я думаю, что моей самой большой проблемой является создание CVImageBuffer, поскольку я скопировал другие свойства из документации Apple для текстур. Если у кого-то есть дополнительная информация по этому поводу, это было бы здорово.
4. Любые другие рекомендации о том, как я могу получить изображение из памяти на экране со скоростью 30 кадров в секунду.

Фон (лоты):

Я работаю над проектом, в котором мне нужно изменить пиксели данных изображения NPOT в реальном времени (минимум 30 кадров в секунду) и нарисовать их на экране в iOS.

Моя первая мысль заключалась в том, чтобы использовать OpenGL с glTexSubimage2D для обновления, но, к сожалению, это оказалось очень медленным (6 кадров в секунду на iPad), поскольку драйвер переключает и преобразует мои данные RGB каждый кадр в BGR. Так что отправьте это в BGR, вы говорите, и я тоже, но по какой-то причине вы не можете вызвать glTexSubImage2D с GL_BGR go figure. Я знаю, что некоторая медлительность связана с тем, что это не мощность двух данных изображения, но мои требования диктуют это.

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

В любом случае, отказавшись от своего достоинства, сбросив OpenGL и переключив свои мысли на CoreGraphics, я пришел к этому вопросу самый быстрый способ нарисовать экранный буфер на iphone, который рекомендует использовать CGImage, поддерживаемый CGDataProviderCreateDirect, который позволяет вам возвращать указатель на данные изображения, когда это необходимо CGImage, прекрасно, верно ? Ну, похоже, это не совсем так, как рекламируется. Если я использую CGContextDrawImage, то все работает. Я могу изменить буфер пикселей, и каждый розыгрыш, он запрашивает данные изображения у моего поставщика данных, как и должен, вызывая методы в CGDataProviderDirectCallbacks (Note: они, похоже, имеют встроенную оптимизацию, игнорируют обновленный указатель, если он имеет тот же адрес как предыдущий). CGContextDrawImage не очень быстрый (около 18 кадров в секунду) даже с отключением интерполяции, которое увеличило скорость примерно до 6 кадров в секунду. В документации Apple говорится, что использование self.layer.contents будет намного быстрее, чем CGContextDrawImage. Использование self.layer.contents работает для первого назначения, но CGImage никогда не запрашивает перезагрузку у поставщика данных, как это делает CGContextDrawImage, даже когда я вызываю [layer setNeedsDisplay]. В вопросе SO, на который я ссылался, пользователь показывает свое решение проблемы, создавая и уничтожая новое изображение CGImage из источника данных в каждом кадре, безнадежно медленный процесс (да, я пробовал), так что время для настоящего вопроса.

Примечание. Я профилировал все эти операции и знаю, что проблема действительно glTexSubImage для OpenGL, а CGContextDrawImage действительно проблема от CoreGraphics, поэтому никаких ответов "перейти в профиль" нет.

ИЗМЕНИТЬ. Исходный код, демонстрирующий эту технику, теперь можно найти по адресу http://github.com/narpas/image-sequence-streaming