Запаковка картинок в памяти

[s8000_1]

Есть очень много векторых картинок, рестеризованных в массив BitmapData. Есть задача их как-то запаковать в byteArray, чтобы они занимали меньше места в памяти. Использовал PNGEncoder2, который в свою очередь использует domainMemory, но получается неприемлемо долго. Может, есть способ запаковать картинку без потери качества как-то иначе, кроме png?

[Aquahawk]

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

[expl]

Есть способ упаковкой ByteArray::deflate и ByteArray::inflate. Пытался использовать для аналогичных целей - но запаковка тоже слишком медленная.
Видимо остаётся только мудрить с убиранием из памяти не используемого отрендеренного после истечения заданного времени. А если ещё раз потребуется - снова рендерить.

[s8000_1]

Aquahawk, ваш ответ выглядит примерно так "Не понимаю, зачем вы это тут написали, но я не знаю, как вам ответить"

expl, а с domainMemory не мудрили?

[expl]

expl, а с domainMemory не мудрили?

А чего с ней мудрить, если _нативные_, написанные на сях, методы сжатия ByteArray не дают нужной производительности (распаковка - ещё полбеды, но запаковка в 30 раз медленнее)

Правда, сейчас идейка появилась, что если быстренько, ничего не сжимая, просто порезать цвета каждого пикселя картинки через эти опткоды работы с domainMemory - получится быстрее сжатия (с потерей цветов)

vector<->BitmapDAta<->LowColorByteArray
Вообще, если подумать, далеко не факт, что BitmapDAta<-LowColorByteArray (а уж BitmapData<-byteArray.inflate() - тем более) будет быстрее рендеринга вектора. И если это действительно не быстрее - то смысла делать промежуточное хранение нет. Только хитрую систему собирать.

Если есть желание, можете поискать какой-нибудь неэффективный, но жутко быстрый алгоритм сжатия/распаковки изображений (буде таковой в природе)

[dimarik]

Сообщение от s8000_1

Есть очень много векторых картинок, рестеризованных в массив BitmapData. Есть задача их как-то запаковать в byteArray, чтобы они занимали меньше места в памяти. Использовал PNGEncoder2, который в свою очередь использует domainMemory, но получается неприемлемо долго. Может, есть способ запаковать картинку без потери качества как-то иначе, кроме png?

Звучать должно так: есть много данных, жрут много памяти, нужно упаковать, пусть жрут больше времени на распаковку.

Но "вектор" и есть компактная упаковка для многих представлений. Если у вас полноцветные сложные картинки хранятся в векторном виде, то это явно глупый оверхед. А если простые, то зачем хранить их в битмапдате? Зря вы к Aquahawk не прислушались. На iPad 1 все равно не взлетит.

[expl]

Стоп, типичная ситуация:
Есть куча векторной анимации (она, может даже из растровых кусков состоит). Если ее загнать в простую растровую последовательность кадров, даже с очень большим сжатием с потерями, вес будет в пару десятков раз больше.
Т.е. проблема:
1. Рендерится флешплеером долго
2. Пререндеринг в несжатые BitmapData ест очень много памяти
Что здесь нетипичного? И какое здесь может быть "простое" правильное решение?

Звучать должно так: есть много данных, жрут много памяти, нужно упаковать, пусть жрут больше времени на распаковку.

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

Ещё вспомнил:
Один товарищ применял такой способ управления ресурсами (без ручной пометки ресурса неактивным и без ручного удаления по истечении определенного времени неиспользования):
Он просто делал доступ к ресурсам через Dictionary с wearReference=true, объект ресурса брался по url. Т.е. если на ресурс нет ни у кого ссылок - то он должен снестись когда-нибудь GC. А при повторном запросе если его уже снесли - соотвественно загрузиться/отрендериться заново.
(У него это в достаточно большом проекте работало. Хотя у меня как-либо сэмулировать убирание GC после прибивания всех ссылок на ресурс не получилось - можете попробовать сами)

[dimarik]

Дык все равно на iPad не взлетит. Хоть доужимайся. PNG и так уже ужат до нехочу. Еще Inflate? Глупость. Прикол только в том, что в памяти это изображение находится в развернутом виде. Смысл сжатия исходного материала минимален, но не неощутим.

[expl]

А кто говорит об ужатии исходного материала? Вроде исходный - вектор. Тут же речь про попытку как раз сохранить компактно в памяти эту отрендеренную BitmapData. И iPad то причём? Всмысле если на нем взлетит по памяти, но будет тормозить по производительности - какой смысл.

Или Вы предлагаете вообще исходники в PNG/JPG пожать - так грузить же долго - различие в десятки раз.

[s8000_1]

dimarik, анимации и картинки изначально векторные. Их сложность и количество снижают FPS на 50% на ноутах 2-3 летней давности. Пререндеринг вообще всей игровой сцены со всеми анимациями (даже по частям) съедает ~1гб оперативки, но я считаю, что нормально - это около 500мб. Приходится исхитряться с пререндерингом сложных будущих анимаций на лету асинхронно с текущими, засекая время пререндера каждого кадра, чтобы не убивать FPS. В принципе работает очень хорошо без падения FPS на очень старых компах, но иногда возникает лаг в 1-2с тогда, когда прошлая анимация выполнилась, а новая ещё не отрендерилась. Я заполняю этот лаг комиксным бабблом над персонажем с его "мыслями" по поводу игровой обстановки. Но всё равно это слегка раздражает.

Потому и спросил, может, я не знаю о каком-то способе быстрой запаковки/распаковки изображений. Распаковка всё равно быстрее растеризации. Например loadBytes 500 png-кадров занимает 200мс, против 800мс на растеризацию этих же кадров из вектора в bitmapdata.

expl, по поводу цветов хорошая мысль, подумаю в эту сторону, спасибо. Ещё была мысль у меня собирать несколько кадров на 1 BitmapData и как-то хитро их размещать и размечать области, которые надо копировать. Тогда порежутся много прозрачностей, которые занимают место.