Android OpenGL ES через NDK: размещение декомпрессии jpg и привязка к текстуре - PullRequest
1 голос
/ 10 декабря 2011

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

Я пишу приложение для Android OpenGL ES 1.1. Он использует NDK: ядро ​​рендеринга OpenGL написано в нативном коде, очень похоже на пример OpenGL san-angeles , который поставляется с NDK. Я использую текстуры OpenGL, которые считываются в приложение как JPG. Я знаю, как это сделать, но мне интересно, это самое эффективное место для этого (под эффективным я подразумеваю быстрое выполнение).

Чтобы проиллюстрировать, вот несколько сценариев для привязки текстур OpenGL на основе входных JPG в моем проекте:

1) Код Java создает растровое изображение из JPG (т.е. распаковывает его), а также связывает и загружает текстуру, используя привязки Java OpenGL. Идентификаторы текстуры передаются через NDK в собственный код, чтобы нативный код мог использовать их для наложения текстуры.

2) Код Java создает растровое изображение из JPG (то есть распаковывает его) и передает необработанные данные изображения через NDK в собственный код, который затем связывает и загружает текстуру из этих необработанных данных изображения.

3) Код Java проходит через данные JPG (сжатые) через NDK в собственный код, который распаковывает растровое изображение, а затем связывает и загружает текстуру.

Я использую NDK и собственный код не по соображениям скорости, а по соображениям переносимости - я хочу, чтобы мой основной код OpenGL работал на iPhone и Android, так же, как в примере san-angeles OpenGL это идет с NDK. Я знаю, что native не всегда быстрее, чем код Java.

1 Ответ

3 голосов
/ 10 декабря 2011

** Собственная распаковка jpeg будет быстрее, чем реализация Java, при условии, что оба используют один и тот же алгоритм. Разница, однако, не будет существенной. **

Для переносимости я сохраняю как можно больше кода. Таким образом, когда я перемещаюсь между платформами, мне очень мало нужно сделать для создания порта. Я использовал SOIL для распаковки JPG-файлов в нативном коде и обнаружил, что производительность сопоставима с версией для iOS с тем же кодом. Конечно, Android не кажется медленнее.

Что касается активов, я обнаружил, что распаковка ZIP была очень медленной. Значительно изменив расширение в ресурсах до загрузки MP3. К счастью, MP3 не сжимаются. Когда пакет Android создан, все файлы в папке ресурсов помещаются в APK. APK представляет собой zip-файл, содержащий приложение, ресурсы и ресурсы. Когда пакет сделан, некоторые файлы добавляются в zip-файл без сжатия. Одним из них является MP3. Переименовывая файлы в MP3, они добавляются в несжатом виде и поэтому загружаются намного быстрее.

Мой субъективный ответ на ваш вопрос будет

4) Все ваши загрузки текстур и управление активами в Native Code, используя тот же код, который вы используете для iOS. Для распаковки jpeg используйте libjpeg-turbo или SOIL, SOIL проще, libjpeg-turbo очень быстрый. Получите доступ к своим ресурсам с помощью libzip и libz, убедившись, что вы добавляете расширение MP3 в каждый файл, чтобы предотвратить сжатие zip.

ПОЧВА http://www.lonesock.net/soil.html

LIBZIP http://www.nih.at/libzip/

LIBZ доступен в NDK

libjpeg-turbo http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.git;a=summary

...