-
Запись понравилась
-
0
Процитировали
-
0
Сохранили
-
-
Запись понравилась
-
0
Процитировали
-
0
Сохранили
-
Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина Flash Player. Иследования проводились только для версии 11.1 standalone debugger for win32. В следующих версиях Flash Player могли как улучшить работу с памятью так и ухудшить, но скорее всего всё осталось также. Итак, garbage collector (GC) исключительно хреново работает с памятью. Он её попросту не очищает во многих случаях или выделяет в разы больше чем требуется.
Вы наверняка знаете, что такое сильные и слабые ссылки и как GC их считает чтобы понять нужен этот объект или нет... Всё это написано во многих местах, в т.ч. в документации по AS3. Я всё это повторять не буду. Здесь описано как всё должно хорошо очищаться:
http://help.adobe.com/en_US/as3/mobile/flashplatform_optimizing_content.pdf
Но нифига оно так не работает к сожалению. При соблюдении всех этих правил моя программа всё равно жрала память как сумасшедшая при загрузке, а потом Flash Player просто падал, когда кончалась физическая память в операционной системе. Вот так он работает на самом деле.
Всё началось вот с этой темы в Juick:
http://juick.com/eugene20237@ya.ru/2009006 и моего вопроса на StackOverflow:
http://stackoverflow.com/questions/11833009/as3-bitmapdata-memory-leaks
Почитайте, если хотите, узнаете много нового о флеше. А ещё почитайте вот
эту статью о том что надо реально сделать для оптимизации по памяти на флеше.
Дальше уже обнаружились другие интересные особенности. Моя оптимизация касалась в основном выделения памяти для множества картинок, на которых у меня строятся кадры анимации. Далее я просто резюмирую выводы, к которым пришел в ходе многочасовых экспериментов с
BitmapData.
- Loader в дефолтном своем применении порождает утечки памяти. Поэтому если через него загружается картинка, то надо брать её BitmapData и делать bitmapData.clone(), сохраняя в другую переменную. А потом диспозить существующую картинку в Loader, а затем делать loader.unload(). Ещё на всякий случай можно cacheAsBitmap=false.
PHP:
var bitmapData:BitmapData = (loader.contentLoaderInfo.content as Bitmap).bitmapData.clone();
(loader.content as Bitmap).cacheAsBitmap = false;
(loader.content as Bitmap).bitmapData.dispose();
(loader.content as Bitmap).bitmapData = null;
(loader.contentLoaderInfo.content as Bitmap).bitmapData = null;
loader.unload();
font>
Только тогда он работает нормально. И то с учетом, что память очищается секундой позднее. Но очищается. Во всех остальных случаях можно сушить вёсла... При этом Loader остаётся единственным способом загружать картинки без утечек памяти.
- C Embed ресурсами всё гораздо хуже. Под них выделяется всегда в разы больше памяти (в 2 раза обычно) и далее она не очищается никогда. Поэтому просто так Embed ресурсы использовать нельзя. Причина заключается в том, что они построены на Flex-компонентах, а в них много неоптимальной фигни. Юзайте Loader. А если нужно встроить ресурс в приложение, то делайте бинарный Embded, а затем Loader.loadBytes(...). Другого пути пока не найдено.
PHP:
[Embed(source="../media/128.png", mimeType="application/octet-stream")]
static private const EmbedBMP:Class;
..............
loader.loadBytes(new EmbedBMP() as ByteArrayAsset);
font>
- Использовать много мелких картинок - плохая идея. Флеш будет выделять больше памяти чем требуется. Если же для большой группы картинок (допустим 100 шт.) вызывается dispose(), то их память будет очищена, но не сразу, а как повезет: может через минуту или как угодно Богу Мусорщику. Если же использовать десяток больших картинок (допустим 4096x4096), то память под них будет выделять и очищаться абсолютно корректно и сразу же.
- Выделение памяти под BitmapData происходит не при создании объекта BitmapData, а при первой операции рисования на ней или копирования данных пикселей в неё. Это внутренняя оптимизация BitmapData.
- Говорят, что BitmapData иногда выделяет памяти больше чем надо из-за внутреннего мипмеппинга. Этот мипмеппинг отключить никак нельзя. Также есть информация, что он отключается, если задать размеры картинки не являющиеся степенью двойки. У меня на практике это совсем не подтвердилось, так что никакой возможности управления мипмеппингом скорее всего уже нет.
- Сюда же поделюсь опытом использования трюка с local connection. Так вот, в исходном варианте этого хака LocalConnection создаётся два раза внутри try. Мои эксперименты показали, что надо вписать там три строчки, а не две. Вот так:
PHP:
public static function freeMemoryGC(): void
{
// the GC will perform a full mark/sweep on the second call.
try
{
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
}
catch (e:*)
{
}
//System.gc();
}
font>
В этом случае вероятность очистки памяти сразу гораздо выше (почти всегда сразу очищается). Если сделать два раза эту инструкцию, но вызвать тоже самое хотя бы через 100 мс, то память также очиститься. System.gc() не использую потому что он работает только AIR или только в отладочной версии Flash Player. Кроме того советую почитать эту тему о способах принудительного пинания GC. В частности в ней есть ссылка на такой способ.
-
Запись понравилась
-
0
Процитировали
-
0
Сохранили
-
Пару дней ковырялся чтобы настроить IDE для серверной и клиентской части одного проекта. Захотелось мне заставить IDE одновременно работать как серверной так и с клиентской частью чтобы не тратить внимание на переключение между разными средами. Сложность в том, что клиент и сервер на разных языках, соответственно на Флеше и на Питоне. И вот наконец получилось!
В качестве основы взял среду FDT4, потому что она быстрая и на ней уже работает Флеш. Установил в неё PyDev и кучу разных плагинов, в т.ч. для синхронизации с удалёнными серверами. Серверную часть пока запускаю на той же машине, что и клиентскую, но ничто не мешает и править серверный код удаленно потому что есть RSE для Эклипса. Отдельная проблема была с FlashPlayer, потому что для юнит-тестов он совершенно не нужен и его окошко надо было спрятать. Как это сделать нормально пока не знаю, может быть надо писать тесты на Adobe AIR. Я же извратился и вызываю плеер через браузер в одной и той же вкладке, а само окно браузера скрыл навсегда сторонней утилиткой. В результате у меня получилась IDE с двумя консолями и двумя проектами, где ничто не отвлекает от сути.
-
Запись понравилась
-
0
Процитировали
-
0
Сохранили
-
Многие игровые движки, в частности на флеше, используют для анимации всяких взрывов и других эффектов большие картинки, в которых содержатся все изображения анимированного спрайта. Нормальных цивильных программ для этой простой задачи компоновки я найти не смог.
Есть утилита, которая называется "SpriteImage Composer", очень старая и глючная. Она делает именно то, что требуется и до недавнего времени я пользовался ей. Она сохраняет коллекцию спрайтов в один большой PNG файл. Однако проблема в том, что эти файлы слишком много весят, если хранить в них длительную анимацию. Например, 4 секундный ролик размером 128x128 в таком формате занимает уже более 1 Мб. Если таких анимаций будет много, то суммарный размер данных для игры уже является неприемлемо большим.
Решение придумал следующее. Для анимационных эффектов не особо важна точность деталей картинки, поэтому её можно сжимать с потерями, т.е. в JPEG. Но JPEG не поддерживает прозрачность. Как же быть? А вот как: собираем все спрайты в большую картинку, а потом сохраняем её в виде двух частей. Первая часть - сама картинка анимаций в виде JPG-файла, а вторая - альфа канал, тоже в виде отдельного JPG-файла. Затем в целевом приложении загружаем оба файла, компонуем в единую картинку с прозрачностью и разбиваем по кадрам. Преимущество такого подхода в том, что суммарный размер пары JPG-файлов в несколько раз меньше, чем единая PNG-картинка.
Именно этот подход использует моя крохотная утилитка, написанная под Adobe AIR. Скачать её и использовать может каждый разработчик, столкнувшийся с этой элементарной проблемой:
http://code.google.com/p/fire-starter/
Программа является OpenSource'ной - берите и делайте с ней всё, что хотите.
-
Запись понравилась
-
0
Процитировали
-
0
Сохранили
-
Свершилось!!!
Away3D 4.0 public beta now available! (see away3d.com)
Руки чешуться попробывать! Теперь он поддерживает Molehill 3D API.
Для тех кто в танке:
В воскресенье, 27 февраля 2011 года, компания Adobe открыла доступ к бета-версии Molehill 3D API для Flash Player 11. Данная технология задействует для обработки изображения графический процессор видеокарты, позволяя добиться высококачественной современной графики в браузерных приложениях. Скачать первые публичные сборки (билды), документацию и набор инструментов Flex SDK можно с сайта labs.adobe.com из раздела AIR and Flash Player Incubator.
-
Запись понравилась
-
0
Процитировали
-
0
Сохранили
-
Сегодня протестировал детально Away3D 3.6 и Alternativa3D 7.6. Пробывал рендерить от 1 до 10 анимированных персонажей в пустом пространстве. Альтернатива позволяет рендерить с приемлемой производительностью около 6-7 персонажей (~500 полигонов каждый), Away3D позволяет с нормальной скоростью рендерить 4-5. Вывод из этих тестов такой: всё это дерьмо :(
Вот два теста. Модели там к сожалению разные, но прикинуть можно. Вот тест Away3D:
http://dl.dropbox.com/u/493679/benchmark/away3d.swf
А вот тест Альтернативы:
http://dl.dropbox.com/u/493679/benchmark/alternativa3d.swf
Как видно, у Альтернативы полигонов больше, а fps чуть лучше.
Под Молехил Away3D и Alternativa3D будут переделаны в ближайшие полгода, так заявляют сами разработчики. Остаётся ждать. Но ждать просто так скучно :)
