сохранение и чтение данных на клиенте
 

Короткая тема и корткий вопрос.
Суть задачи: сцена предсталяет слбой карту местности, разбитую на 100 битмапов размером 80х80 px, которые отображаются в зависимости от положения viewport'а пользователя (остальные битмапы не отрисовываются), но естессно такае схема мягко говоря кушает много памяти.
Вопрос: логично ли те битмапы, которые не востребованы пользователем временно хранить на жестком диске, а по мере надобности подгружать во флешку, а не используемые в свою очередь скидывать на жесткий? В AS3 реализовать такую схему не составит труда, но как это скажется на производительности? Используются ли такие схемы?

Если приложение не AIR, забудьте про жесткий диск.

Обязательно. В standalone клиентах. Через тырнет браузер сам кеширует файлы. ТОже нет нужды заморачиваться. А вот что означает фраза "а не используемые в свою очередь скидывать на жесткий" я не догнал.

dimarik : removeChild при невидимости( и достаточной удаленности битмапа от видимой области) запись его содержимого в локальное хранилище допустим и освобождение памяти. Просто с нагруженными битмапами плеер жрет через чур много памяти.
А я не догнал если честно : В standalone клиентах. Через тырнет браузер сам кеширует файлы. Как? Мне битмап приходит через сокет соединение, на клиенте он собирается по битам (точнее приходит zip архив), не думаю, что браузер его закеширует, или я не прав?
Может изначально у меня схема очень замороченная?

по сокету гнать зип-архив, в котором лежит картинка ... да не, нормально :) не заморочено. бывает и хуже. например тупо запрашивают по ХТТП.

zafod, чем Вас не устроил вариант с передачей контента по HTTP? А по сокету гонять только данные.

может я конечно не прав, но не вижу смысла в HTTP, если у меня открыто прямое сокет-соединение, гонять данные? - ну так я и гоняю, какая разница, что идет через сокет. Разработан протокол передачи( кривенький правда ), но получив оффсет зип архива он его привот к читабельному виду через класс-обертку Loader'a. Вообще конечно спорный вопрос, я согласен, вариантов куча.
Может вернемся к изначальному вопросу? Нормально скидывать не используемые битмапы через sharedObject на диск?

sharedObject по-моему ограничен на 1мгбайт или что-то около того по умолчанию. Когда израсходованны - спрашивает у пользователя - расширить хранилище или нет. А больше препятствий по-моему нет.

да-да именно так, и пользователь у меня говорит "да". Вопрос - на сколько упадет быстродействие? Потому как у меня получается постоянная (с перерыврм не более минуты) чтение - запись посредствам sharedObject. Соотв. класс для данной схемы практически готов, но не хочется тратить время на заведомо неправильную/медленную схему, поэтому прошу совета, может кто использовал что-то подобное

правильная и быстрая схема - юзать ХТТП.

а почему, можете пояснить? и что конкретно имеется ввиду под этими словами?

я даже не знаю как Вам объяснить. Вы построили схему, до которой додумается не каждый извращенец. теперь Вы хотите к это штуке прикрутить обыкновенное кэширование, которое уже есть на уровне системы при использовании ХТТП. юзать ShredObject нельзя, так как не каждый нажмёт "Да" на непонятном окошке ( а ведь там ещё и ползунком подвигать надо ), зато каждый скажет что всё тормозит. тоесть вместо заранее рабочей схемы, вы выбираете схему, которую:
1. надо реализовывать
2. которая жрёт дополнительные ресурсы, за счёт сокета, зипования, и т.д.
3. к которой невозможно отследить прогресс загрузки ( я так думаю )
4. которая не умеет самостоятельно кэшировать данные
5. которая зависит от действий и "не знаний" пользователя.

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

нельзя

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