Прогресс создания ByteArray

[meiciuc]

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

может, использовать аналогию работы гугл-мэп? систему тайлов, где невидимые тайлы удаляются и освобождают системную память, а при необходимости подгружаются с сервера?

[Alex626]

Я могу разбить одну BitmapData на несколько штук поменьше, затем каждую преобразовать в ByteArray и потом все ByteArray склеить в один, и сохранить. НО! Как я буду склеивать их? Ведь энкодеры дают готовый набор байтов уже с заголовками, да и я думаю ещё с какими-то особенностями, так что простая конкатенация не сработает.

[meiciuc]

в одном из сообщений выше я давал ссылку на Алхимический проект - сейчас даю уточняющую ссылку - https://code.google.com/p/in-spirit/wiki/PNGEncoder

там как раз то, что нужно - возможность склеивать ну просто огромные картинки

пару лет назад у меня был проект, где надо было огромный мувик преобразовывать в bytearray и отправить на сервер. Мувик был гигантский и просто скопировать в битмапдату было нельзя. Помог проект по-ссылке.

Суть видна и в коде РАБОЧЕГО примера, но на всякий случай продублирую тут:
1. совершенно не обязательно для начала иметь исходный битмап - в моем случае это был контейнер с нарезанными битмапами (а-ля тайлы). Флэш плеер никак не ограничивает размер спрайта - только оперативка.
2. кодировщику в качестве параметра передается экземпляр PNGEncoderInfo в котором есть ссылка на метод, который будет "нарезать" единую "картинку" (контейнер с тайлами) на битмапы. Т.е. - имеется мувик-контейнер, который будет скармливаться энкодеру кусочками битмапов, которые, в свою очередь, будут склеиваться в единый ByteArray внутри этого самого энкодера.

надеюсь, поможет

В моем случае, когда код запускался на машине с (дай Бог памяти) 512 MB, изображения кодировались в ByteArray размером до 100 млн. пикселей. На 4 гигах оперативки кодировались картинки такого размера, что их браузер отобразить не может - можно было только скачать с сервака и в графических редакторах увидеть результат.

[AlexCooper]

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

А как-то можно обойти ограничение размера BitmapData.Draw? У меня в системе памяти не хватает на масштабы более 234% (это где-то 20.000 х 20.000 пикс.).

Дык замените

private function encode(bitmapData:BitmapData):void
{
	var jpeg:JPEGEncoderOptions = new JPEGEncoderOptions();
		jpeg.quality = 4;
 
	var byteArray:ByteArray = bitmapData.encode( bitmapData.rect, jpeg);
 
	save( byteArray );
}

на

private function encode(bitmapData:BitmapData):void
{	var j:JPEGAsyncEncoder = new JPEGAsyncEncoder(85);
	j.PixelsPerIteration = 300;
	j.addEventListener(JPEGAsyncCompleteEvent.JPEGASYNC_COMPLETE, handleJPEGEncoder);
	j.addEventListener(ProgressEvent.PROGRESS, handleProgress);
	j.encode(bitmapData);
}

Добавлено через 1 минуту
снимайте битмапу частями и асинхронно конвертируйте

Добавлено через 19 минут

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

НО! Как я буду склеивать их? Ведь энкодеры дают готовый набор байтов уже с заголовками, да и я думаю ещё с какими-то особенностями, так что простая конкатенация не сработает.

Подсмотрев сюда

public function encode(image:BitmapData):ByteArray
                {
                        // Initialize bit writer
                        byteout = new ByteArray();
                        bytenew=0;
                        bytepos=7;
 
                        // Add JPEG headers
                        writeWord(0xFFD8); // SOI
                        writeAPP0();
                        writeDQT();
                        writeSOF0(image.width,image.height);
                        writeDHT();
                        writeSOS();
 
 
                        // Encode 8x8 macroblocks
                        var DCY:Number=0;
                        var DCU:Number=0;
                        var DCV:Number=0;
                        bytenew=0;
                        bytepos=7;
                        for (var ypos:int=0; ypos<image.height; ypos+=8) {
                                for (var xpos:int=0; xpos<image.width; xpos+=8) {
                                        RGB2YUV(image, xpos, ypos);
                                        DCY = processDU(YDU, fdtbl_Y, DCY, YDC_HT, YAC_HT);
                                        DCU = processDU(UDU, fdtbl_UV, DCU, UVDC_HT, UVAC_HT);
                                        DCV = processDU(VDU, fdtbl_UV, DCV, UVDC_HT, UVAC_HT);
                                }
                        }
 
                        // Do the bit alignment of the EOI marker
                        if ( bytepos >= 0 ) {
                                var fillbits:BitString = new BitString();
                                fillbits.len = bytepos+1;
                                fillbits.val = (1<<(bytepos+1))-1;
                                writeBits(fillbits);
                        }
 
                        writeWord(0xFFD9); //EOI
                        return byteout;
                }

можно увидеть

 
// Add JPEG headers
writeWord(0xFFD8); // SOI
writeAPP0();
writeDQT();
writeSOF0(image.width,image.height);
writeDHT();
writeSOS();

соответствено нужно вывести длинну заголовка, и вырезать его перед склейкой.
Только в данном случае стоит учесть что пережимка осужествляется по X, а значит что обычная конкатенация даст распад изображения. Потому или однопиксельная горизонтальная нарезка, или PixelBender перед снятием битмапдаты, который пересоберёт картинку. Но это помоему уже велосипеды

[Alex626]

В общем, соглашусь, что всё это костыли. Поставлю заставку на время кодирования. Всё равно нативный кодер максимум 10 секунд отнимает, это нормально.

У меня последнее предположение насчёт ограничения BitmapData.Draw на компьютерах. Если флеш зависит от размера оперативной памяти, а плеер 32-битный, то скорее всего программе будет максимально доступно только 3,3 Гб. Если я сделаю 64-битное приложение под десктопы на Air, будет ли оно работать там лучше и без ограничений?