Технологии сроллинга больших битмапов
 

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

На ум приходят несколько вариантов скролла такого мира:

Загрузить такой битмап кодом или заранее положить в ide, и

1) При скролле отображать на экране (800*600) только видимую часть используя copyPixels из исходного битмапа

2) создать 3 битмапа шириной в экран(800) и высотой, скажем 2 экрана (1200), где средний - видимый, а крайние - буфферные. Далее они склеиваются и берут содержимое из исходного битмапа. Таким образом склейка из этих 3 битмапов представляет собой часть исходного битмапа, шириной в 3 экрана, но видим мы только средний. Дальше скроллится склейка из этих трёх битмапов.
Затем в нужный момент, буфферные битмапы меняют положение. Так что бы слева и справа снова была "пища для скролла". Таким образом копируем пиксели из исходника только в самом вначале и в момент переноса буфферых битмапов.

Дальше нужно проверять коллизии на уровне пикселей.

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

Вопрос: Какой из этих двух вариантов будет быстрей.

третий будет быстрее, просто заэкстендить классы Bitmap и BitmapData, чтобы их ширина и высота не были ограничены.

я свою пару обозвал SuperBitmap и SuperBitmapData :)


З.Ы если завернуть такой класс в маску (800*600) то будет работать не слишком медленнее обычной Bitmap+BitmapData

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

Но попробовать можно, конечно.

Добавлено через 6 минут
И потом, если экстендить битмап и битмапдату, то надо будет разбивать исходный битмап на кучу кусков и хранить их "склейку". А это значит, что в любой момент в видимой зоне с большой вероятностью будет несколько кусков, и коллизии надо будет проверять со всеми.

Почему?

ну, если они много больше размера экранчика то не больше 4х...

а что, 4000х4000 обычной битмапы не хватит, по отношению к 800х600 это в несколько раз больше?

А что если иметь одну большую битмапу, отрендерить в нее участок и двигать, пока не покажется ее край (скажем, верхний если ее вниз двигать), и перендеривать ее в таком случае со сдвигом ее вверх на 4000 пх?

Кстати, больше 8000х8000 пикселей я б не делал (это 4 битмапдаты) так как на ноутах и нетбуках с такой флешкой могут начаться проблемы, если памяти мало

Была похожая ситуация только в качестве источника был вектор, перемещать его и зумить было просто невозможно. Очень долгий был рендеринг. Выбрал примерно то, что в вашем втором варианте. У меня задача была сделать карту и соответственно прокрутка могла произойти в любую сторону. В итоге получилось 9 битмапов размером с отображаемую область(один видимый и остальные буферные). Для меня это был единственный выход и я думаю наиболее правильный. Перерисовка в данном случае происходит после каждого сдвига(например после отпускании мыши при перетаскивании).