![]() |
Free memory from bitmapdata
Коллеги я так понимаю, что нельзя :
Код AS3:
|
Bitmap только ссылается на BitmapData, он не хранит её копий.
Dispose для BitmapData уничтожит изображение. Bitmap - это просто [абстрактный] класс, который унаследован от DisplayObject, чтобы отображать BitmapData. |
Ну значит я все верно понял о том, что если у меня будет 1 битмапдата и 1000 битмапок, память грузить будет только 1 битмапдата, а не 1000 шутк
|
Ну эти 1000 штук тоже отхавают свой кусок памяти. Но конечно не столько, сколько сожрали бы 1000 BitmapData.
Кстати во флеше есть какая-то встроенная проверка (о которой я узнал случайно), которая не даст даже многократно загрузить одну и ту же картинку с диска |
Цитата:
|
Цитата:
|
Ну т.е. если несколько экземпляров класса Loader грузят один и тот же jpg, например, то их (content as Bitmap).bitmapData — это один и тот же экземпляр BitmapData? И типо если ты диспознешь его в одном загрузчике, то он исчезнет везде?
|
ну конечно же, и перед загузкой программа проверяет, что ты тот же самый файл гузишь, сохранет урлы под капотом наверное, или может потом побайтовое сравнение делает...
|
Если кто-то не понял сарказма СлаваRa, проговорю словами: нет, сколько экземпляров Loader-а загрузят в себя одну и ту же картинку, столько и экземпляров BitmapData, каждый из которых живет своей жизнью и занимает свою память.
P.S. Ложное впечатление об одной BitmapData на всех могло сложиться из-за того, что Flash не грузит файлы своими средствами, а доверяет это браузеру, который кэширует и второй раз не грузит. AIR (или SA проигрыватель) тоже сам файлы не грузит. Он доверяет это дефолтному браузеру системы. На десктопе под виндой это, например IE, на яблоках — Safari, на дроидах — вот этот вот дефолтный, которому я даже имени не знаю. |
Цитата:
Откуда я это узнал. Возник у нас как-то спор с ZackMercury по поводу того, что много загрузчиков созданных одновременно, загрузят пак картинок гораздо быстрее, чем один загрузчик, который будет грузить каждую следующую картинку по завершению загрузки предыдущей. И скинул мне зак свой код, который одинаково быстро отрабатывал и со множеством загрузчиков и с одним. Разница была буквально в несколько милисекунд на сотнях картинок весом по 2 мегабайта. Это привело меня в небольшое замешательство, потому как я был уверен, что мой подход (со множеством одновременных загрузчиков) должен точно работать быстрее. Начал копаться в причинах явления и выяснил, что он просто скопипастил одну и ту же картинку в папку 100 раз. URL'ы получились разные, но фактически данные в самой png одни и те же. Так вот все сразу встало на свои места, когда я поместил в эту папку действиетльно разные картинки. И множество загрузчиков стали загружать весь пак в несколько раз быстрее, чем один. Объясни как это, если не с помощью проверки данных самой картинки? Не смотрел исходники флекса и не углублялся в работу самой виртуальной среды, но что-то мне подсказывает, что там читаются заголовки файлов и, возможно, еще какие-то данные, перед тем, как принимается решение о загрузке Цитата:
Я, кстати, в AIR картинки гружу с помощью FileStream |
Код AS3:
Добавлено через 3 минуты Я вижу 10 разных объектов BitmapData |
Так кто прав то?Мне тоже кажется маловероятным что в разные лоадеры суется одна и та же битмапДата.
|
Ну Костя то нам доказательства предоставит, я думаю, он же не просто так сказал, потому что ему показалось...
|
Цитата:
Цитата:
:P |
Цитата:
Код AS3:
|
т.е. скрина дебаггера не хватило?
То что Костя написал про скорости и т.д., это вообще другая история, конечно же, но он сам это должен понять для начала... |
Цитата:
|
Цитата:
|
Цитата:
|
по ссылке тоже перейти нельзя?
|
можно, но там ничего нет.
|
Цитата:
|
Ну да, видимо, на загрузке экономит, а память все равно выделяет для каждой новый кусок.
|
Цитата:
Сделал вот такой тест Код AS3:
И вот такие получились результаты Цитата:
|
| Часовой пояс GMT +4, время: 03:50. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.