Free memory from bitmapdata
 

Коллеги я так понимаю, что нельзя :

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

Bitmap только ссылается на BitmapData, он не хранит её копий.
Dispose для BitmapData уничтожит изображение.
Bitmap - это просто [абстрактный] класс, который унаследован от DisplayObject, чтобы отображать BitmapData.

Ну значит я все верно понял о том, что если у меня будет 1 битмапдата и 1000 битмапок, память грузить будет только 1 битмапдата, а не 1000 шутк

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

https://cs5.pikabu.ru/images/preview...7135185057.jpg

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

Ну т.е. если несколько экземпляров класса Loader грузят один и тот же jpg, например, то их (content as Bitmap).bitmapData — это один и тот же экземпляр BitmapData? И типо если ты диспознешь его в одном загрузчике, то он исчезнет везде?

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

Если кто-то не понял сарказма СлаваRa, проговорю словами: нет, сколько экземпляров Loader-а загрузят в себя одну и ту же картинку, столько и экземпляров BitmapData, каждый из которых живет своей жизнью и занимает свою память.

P.S.
Ложное впечатление об одной BitmapData на всех могло сложиться из-за того, что Flash не грузит файлы своими средствами, а доверяет это браузеру, который кэширует и второй раз не грузит. AIR (или SA проигрыватель) тоже сам файлы не грузит. Он доверяет это дефолтному браузеру системы. На десктопе под виндой это, например IE, на яблоках — Safari, на дроидах — вот этот вот дефолтный, которому я даже имени не знаю.

А ты проверь.
Откуда я это узнал. Возник у нас как-то спор с ZackMercury по поводу того, что много загрузчиков созданных одновременно, загрузят пак картинок гораздо быстрее, чем один загрузчик, который будет грузить каждую следующую картинку по завершению загрузки предыдущей. И скинул мне зак свой код, который одинаково быстро отрабатывал и со множеством загрузчиков и с одним. Разница была буквально в несколько милисекунд на сотнях картинок весом по 2 мегабайта.
Это привело меня в небольшое замешательство, потому как я был уверен, что мой подход (со множеством одновременных загрузчиков) должен точно работать быстрее. Начал копаться в причинах явления и выяснил, что он просто скопипастил одну и ту же картинку в папку 100 раз. URL'ы получились разные, но фактически данные в самой png одни и те же. Так вот все сразу встало на свои места, когда я поместил в эту папку действиетльно разные картинки. И множество загрузчиков стали загружать весь пак в несколько раз быстрее, чем один.
Объясни как это, если не с помощью проверки данных самой картинки?
Не смотрел исходники флекса и не углублялся в работу самой виртуальной среды, но что-то мне подсказывает, что там читаются заголовки файлов и, возможно, еще какие-то данные, перед тем, как принимается решение о загрузке

SA проигрыватель и AIR это все такие разные вещи. AIR читает данные напрямую с диска, сам. Не нужен ему никакой дефолтный браузер. Браузер ограничивает работу плагинов с файловой системой. А у эйр этих ограничений нет.
Я, кстати, в AIR картинки гружу с помощью FileStream