Сравнение декомпрессии изображения iPad 3

1. 4x Да, верно.
2. Заключение

Из заявлений, сделанных на iPad !!! На стартовом мероприятии мы предположили, что A5X должен быть зверем, разрушающим все предыдущие сделанные тесты. Существуют различные виды измерений, которые вы можете предпринять, чтобы сравнить новый iPad !!! своим предшественникам. Для одного кажется, что мощность процессора в основном без изменений судя по взгляду на Geekbench, который измеряет целочисленные значения, значения с плавающей запятой, память и поток.

Тогда есть сырая графическая производительность, которая может быть измерена с GLBenchmark вот видите айпад !!! сиять или хотя бы немного искриться. Apple явно оптимизировала это, люди ожидают, что по крайней мере такая же плавная частота кадров на Retina при игре в игры, как и у iPad 2.

Но когда вы на самом деле заинтересованы в вычислительной мощности или графической мощности OpenGL? Что нас больше интересует, так это то, как быстро iPad может взять файл на диск, распаковать его и отобразить на экране. Мы ранее сделали всеобъемлющий Тест декомпрессии изображений сравнить все устройства iOS в этом отношении. Теперь у нас есть цифры для нового iPad, так что давайте сравним!

Арун Сиррпи из Австралии был очень любезен, чтобы запустить наш тест декомпрессии изображений ( доступно на GitHub ) на своем новом iPad и записал номера для нас. Этот тест измеряет продолжительность для 3 фаз: выделение / инициализация UIImage, время распаковки, время рисования. Это объясняется гораздо более подробно в предыдущая статья ,

Номера, где для iPad 2 разрешение:

и для iPad !!! Разрешение сетчатки:

Исходя из этих цифр, мы предположили, что Apple запустит Retina-iPad только в том случае, если они смогут ускорить декомпрессию изображения в 2-4 раза. Загружаемое изображение по умолчанию, которое отображается при запуске приложения, занимает около 100 мс для декодирования и отображения на iPad 2. Это можно видеть в качестве первого столбца в столбце «PNG Crushed». Изображение по умолчанию для размера Retina будет отображаться на iPad 2 в течение 400 мс.

Мы полагали, что Apple никогда не выпустит технологию, которая будет ощущаться намного медленнее. Если бы они могли в четыре раза увеличить скорость декомпрессии, чтобы и изображения Retina могли отображаться за 100 мс, то, как мы думали, это чувствуется так же быстро.

4x Да, верно.

Запуск изображений является лишь одним из факторов, почему производительность распаковки изображений является ключевым для большинства современных приложений для iPad. Подумай обо всех журналы а также каталоги , Все, что будет с полностраничной графикой, зависит от возможности распаковывать их и быстро отображать. В идеальном мире вам потребуется менее 16 мс (60 кадров в секунду) для декодирования и отображения страницы. Но ни iPad 2, ни iPad 3 не могут этого достичь. Вот почему мы, разработчики, вынуждены прибегать к всевозможным трюкам (фоновый рендеринг), чтобы пользовательский интерфейс чувствовал себя гладко.

Хорошо, я надеюсь, вы получите представление и методологию. Без лишних слов давайте сравним фактические цифры. Мы рассмотрим 1024 * 768 и 2048 * 1536, одинаковые размеры для необработанной производительности и Retina для non-Retina, чтобы сравнить «чувствительную производительность». Мы сравним 80% JPEG, потому что это коэффициент сжатия, который оказался визуально неотличимым от несжатых изображений для страниц каталога полного кадра.

PNG Crushed, 1024 * 768 (инициализация + декодирование + рисование)

• iPad 2: 5 мс + 89 мс + 18 мс = 113 мс
• iPad 3: 1 мс + 50 мс + 18 мс = 69 мс

- 47%

JPG 80%, 1024 * 768 (init + decode + draw)

• iPad 2: 2 мс + 32 мс + 18 мс = 52 мс
• iPad 3: 2 мс + 32 мс + 17 мс = 51 мс

- 2%

PNG Crushed, 2048 * 1536 (инициализация + декодирование + рисование)

• iPad 2: 5 мс + 266 мс + 96 мс = 368 мс
• iPad 3: 2 мс + 171 мс + 66 мс = 238 мс

-33%

JPG 80%, 2048 * 1536 (init + decode + draw)

• iPad 2: 1 мс + 121 мс + 69 мс = 192 мс
• iPad 3: 1 мс + 122 мс + 66 мс = 189 мс

- 2%

Так что на первый взгляд я должен сказать, что это не выглядит хорошо для улучшения 4х, на которое мы надеялись. С некоторой доброй волей мы можем дать Apple 2-кратное улучшение (-50%), которое они заявили по сравнению с A5. Но эта добрая воля нарушается при работе с JPEG, потому что кажется, что не все в Apple получили памятку. Сокращенные PNG имеют улучшенное время обработки между 33% и 47%, JPEG только 2%. Во всяком случае, это может быть связано с небольшим улучшением времени чтения SSD.

О «ощущаемой производительности», а именно: чувствует ли приложение быстрее на iPad 3?

Не так уж и много, первоначальный стартовый образ будет отображаться через 113 мс на iPad 2, но на iPad 3 - 238 мс. Если других оптимизаций нет - помните, производительность процессора такая же - тогда приложения будут использовать 125 мс дольше, чтобы начать на iPad 3.

Самая большая проблема, которую я предвижу для разработчиков iOS журналов и каталогов, - это «чувствующая производительность». Даже при использовании 80% JPEG для отдельных страниц вы получаете только 5 кадров в секунду (128 мс на изображение) против 19 кадров в секунду (52 мс) для полноэкранных изображений. Это можно увидеть как рывок при прокрутке с одной страницы на другую, если разработчики декодируют и рисуют страницу в главном потоке.

Заключение

Теперь мы знаем, почему A5X называется так. По сути это тот же процессор, что и у A5 с немного улучшенной графикой. Компьютерщик в нас вычисляет X, чтобы быть около 1.4. Но только для PNG. Или, может быть, JPEG в обновлении iOS.

Вполне возможно, что часть iOS, которая используется для аппаратного ускорения распаковки изображений JPEG, была каким-то образом забыта или не была готова к первоначальной версии iOS 5.1, которая поставляется предварительно установленной в iPad !!!, если это так мы получили бы огромный прирост производительности с 2% до 40%, как с PNG. Это немного смущает Apple, поэтому мы можем предположить, что это не будет обсуждаться, а скорее подкрадывается к «различным улучшениям производительности». #JPEGate

Для нас, разработчиков, это должно срочно позвонить, чтобы разработать методы, которые могут дать нам богатые интерактивные журналы / каталоги без необходимости полноэкранного изображения. Как насчет упаковки только изображений и использования отличного фреймворка с открытым исходным кодом, такого как наш DTCoreText вместо рендеринга расширенного текста? Просто говорю'!

связанные с

Похожие

Комментарии