В качестве оптимизации первого порядка мы могли бы создать битовые образы строк символов валюты для каждой страны, то есть растровое изображение 30×10 пикселей для строки $$$ и аналогичные изображения для других видов валют. Вероятно, такие битовые образы можно было бы очень быстро копировать поверх нашего фонового изображения, предусмотрев для этого цикл, который выполнялся бы столько раз, сколько необходимо, с последующим отсечением верхушки символов в соответствующих точках, чтобы обеспечить нужную высоту столбцов. В действительности, мы можем поступить еще лучше. Почему бы не заготовить заранее битовые образы, представляющие для каждой валюты столбцы максимальной высоты? Всего нам нужно четыре таких заготовки: одна для США (US), одна для Японии (Japan), одна для Великобритании (UK) и одна для стран Европейского Союза (EU). Когда нашему приложению необходимо нарисовать любой из этих столбцов, оно просто использует соответствующий битовый образ и копирует его часть на поверхность нашего рисунка. Как и в случае фонового изображения, если имеется возможность создавать изображения на стадии проектирования, то можно прибегнуть к услугам дизайнеров, которые придадут изображениям максимально привлекательный внешний вид. Пример таких заранее заготовленных столбцов представлен на рис. 11.9.
Рис. 11.9. Заранее заготовленные декорированные столбцы гистограмм
Какой дополнительный объем памяти потребуется для реализации такого подхода? Предположим, что максимальная высота столбцов составляет 180 пикселей, а их ширина — 32 пикселя. Пусть, далее, для хранения информации о цвете каждого пикселя требуется 4 байта. Тогда для хранения в памяти битового образа одного столбца диаграммы потребуется 180×32×4 = 23040 байт, или 22,5 Кбайт. В зависимости от ситуации такой объем может быть для нас как приемлемым, так и неприемлемым. Насколько велик этот объем по сравнению с теми объемами памяти, которые требуются для хранения других объектов? Если предположить, что размеры фонового изображения составляют 200×200 пикселей, то для него потребуется 200×200×4 = 156,25 Кбайт памяти.
Для построения окончательного изображения диаграмм нам потребуется еще одна битовая карта такого же размера, на которую будут копироваться графические данные заднего и переднего планов; в результате этого суммарный необходимый объем памяти достигает 312,5 Кбайт, что не так уж мало, но вполне приемлемо для большинства мобильных устройств. Битовые образы всех четырех столбцов суммарно потребуют 22,5×4=90 Кбайт, что значительно меньше того, что требуется для фонового изображения и пустой битовой карты, на которой все наши изображения будут объединены в одно целое. Учитывая тот факт, что, затрачивая 90 Кбайт дополнительной памяти, мы избавляемся от необходимости многократно создавать в памяти копии небольших изображений или каждый раз рисовать текст поверх столбцов, такую оптимизацию, по всей видимости, можно считать эффективной.
Пример 2: предварительная визуализация объектов для сюжетной игрыЛюбопытно отметить, что оптимизация визуализации изображений для сюжетных игр имеет много общего с оптимизацией этого процесса, которую мы рассмотрели на примере диаграмм. На рис. 11.10 представлено изображение для сюжетной игры, которую я написал для .NET Compact Framework, чтобы продемонстрировать концепции графики.
HA ЗАМЕТКУ
Те, кого интересует исходный текст этого приложения, могут найти его на Web-сайте. Приложение было написано на языке VB.NET и названо "HankTheCaveMan" ("Пещерный человек Хэнк"). Оно позволяет продемонстрировать многие из концепций графики, которые обсуждаются в этой главе. Полный исходный код приложения доступен для загрузки на сайте обмена исходными кодами www.gotdotnet.com вместе с бесчисленным множеством других примеров и информации.
Рис. 11.10. Сюжетная игра, написанная для .NET Compact Framework
Существует три слоя изображений для игр, которые должны визуализироваться на экране: