|
|
|||||
[+4 06.05.14]
|
Free memory from bitmapdata
Коллеги я так понимаю, что нельзя :
Ну то есть - выкинуть из мемори битмапдату, оставив за собой только битмап, я так понимаю в памяти оно не хранится, пока битмап не на экране, а уж раз на экране, то хранится в единственном экземпляре?
__________________
Марк Tween |
|
|||||
Bitmap только ссылается на BitmapData, он не хранит её копий.
Dispose для BitmapData уничтожит изображение. Bitmap - это просто [абстрактный] класс, который унаследован от DisplayObject, чтобы отображать BitmapData.
__________________
There is no thing in this world that is not simple. |
|
|||||
Ну эти 1000 штук тоже отхавают свой кусок памяти. Но конечно не столько, сколько сожрали бы 1000 BitmapData.
Кстати во флеше есть какая-то встроенная проверка (о которой я узнал случайно), которая не даст даже многократно загрузить одну и ту же картинку с диска
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
__________________
while(live()) { hope(); } |
|
|||||
Типа того) Точнее картинку-то он формально загрузит (загрузчики все пошлют события завершения, при чем сразу) и новую BitmapData не создаст, если такая уже была создана
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Lorem ipsum
|
Ну т.е. если несколько экземпляров класса Loader грузят один и тот же jpg, например, то их (content as Bitmap).bitmapData — это один и тот же экземпляр BitmapData? И типо если ты диспознешь его в одном загрузчике, то он исчезнет везде?
__________________
Поймай яблоко 2! |
|
|||||
ну конечно же, и перед загузкой программа проверяет, что ты тот же самый файл гузишь, сохранет урлы под капотом наверное, или может потом побайтовое сравнение делает...
__________________
местонахождение |
|
|||||
Lorem ipsum
|
Если кто-то не понял сарказма СлаваRa, проговорю словами: нет, сколько экземпляров Loader-а загрузят в себя одну и ту же картинку, столько и экземпляров BitmapData, каждый из которых живет своей жизнью и занимает свою память.
P.S. Ложное впечатление об одной BitmapData на всех могло сложиться из-за того, что Flash не грузит файлы своими средствами, а доверяет это браузеру, который кэширует и второй раз не грузит. AIR (или SA проигрыватель) тоже сам файлы не грузит. Он доверяет это дефолтному браузеру системы. На десктопе под виндой это, например IE, на яблоках — Safari, на дроидах — вот этот вот дефолтный, которому я даже имени не знаю.
__________________
Поймай яблоко 2! |
|
|||||
Цитата:
Откуда я это узнал. Возник у нас как-то спор с ZackMercury по поводу того, что много загрузчиков созданных одновременно, загрузят пак картинок гораздо быстрее, чем один загрузчик, который будет грузить каждую следующую картинку по завершению загрузки предыдущей. И скинул мне зак свой код, который одинаково быстро отрабатывал и со множеством загрузчиков и с одним. Разница была буквально в несколько милисекунд на сотнях картинок весом по 2 мегабайта. Это привело меня в небольшое замешательство, потому как я был уверен, что мой подход (со множеством одновременных загрузчиков) должен точно работать быстрее. Начал копаться в причинах явления и выяснил, что он просто скопипастил одну и ту же картинку в папку 100 раз. URL'ы получились разные, но фактически данные в самой png одни и те же. Так вот все сразу встало на свои места, когда я поместил в эту папку действиетльно разные картинки. И множество загрузчиков стали загружать весь пак в несколько раз быстрее, чем один. Объясни как это, если не с помощью проверки данных самой картинки? Не смотрел исходники флекса и не углублялся в работу самой виртуальной среды, но что-то мне подсказывает, что там читаются заголовки файлов и, возможно, еще какие-то данные, перед тем, как принимается решение о загрузке Цитата:
Я, кстати, в AIR картинки гружу с помощью FileStream
__________________
Ко мне можно и нужно обращаться на ты) |
Часовой пояс GMT +4, время: 20:37. |
|
« Предыдущая тема | Следующая тема » |
|
|