11. Нарисовать таблицу цветовых ключей, идентифицирующих наборы данных.

12. Нарисовать рамку. (Создается и уничтожается перо White Pen.)

13. Нарисовать шаблонные линии для каждого набора данных. (Создаются и уничтожаются перья Red Pen, Orange Pen, Yellow Pen и Green Pen.)

14. Нарисовать текстовые подписи для каждого набора данных. (Создаются и уничтожаются кисти Red Brush, Orange Brush, Yellow Brush и Green Brush, создается и уничтожается шрифт 8 пунктов.)

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

Рассмотрим более рациональный вариант организации процесса построения графиков.

Создание ресурсов

1. Создать битовую карту (150×150 пикселей), если до этого память для нее не была распределена.

2. Создать необходимые перья: Red Pen, Orange Pen, Yellow Pen, Green Pen и Blue Pen.

3. Создать необходимые кисти: White Brush, Red Brush, Orange Brush, Yellow Brush и Green Brush.

4. Создать необходимые шрифты: шрифт 8 пунктов.

5. Очистить битовую карту.

6. Скопировать фоновое изображение на битовую карту.

7. Вычертить координатные оси.

8. Рассчитать количество делений на каждой из осей.

9. Вычертить все линии делений.

10. Нарисовать текст для каждого деления.

11. Нарисовать данные для каждого из наборов данных, для которых строятся графики.

12. Нарисовать линии между точками.

13. Вычертить квадраты вокруг каждой точки.

14. Нарисовать название графика.

15. Нарисовать таблицу цветовых ключей, идентифицирующих наборы данных.

16. Нарисовать рамку.

17. Нарисовать шаблонные линии для каждого набора данных.

18. Нарисовать текстовые подписи для каждого набора данных.

19. Освободить память, занимаемую перьями, кистями и шрифтами. 

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

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

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

Чтобы проиллюстрировать это положение рассмотрим два типичных случая.

На рис. 11.7 приведена довольно красочная картинка, на которой некие (фиктивные) данные отображаются в виде гистограммы. Гистограмма представляет относительные темпы роста экономики различных стран за определенный период времени. Чтобы облегчить визуальное восприятие данных пользователем, было решено представить данные, относящиеся к каждой из стран, в виде столбцов, раскрашенных символами валюты данной страны. Кроме того, для диаграммы предусмотрено фоновое изображение; в данном случае таковым является простой градиентный фоновый цвет, плавно меняющийся от темного к светлому оттенку, но вместо него может быть использовано любое изображение

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

Рис. 11.7. Гистограмма, представляющая темпы роста экономики различных стран

Первое, что мы можем сделать в плане оптимизации, — это определить все то, что будет оставаться неизменным в любой диаграмме, и превратить эти объекты в готовый фон. Сказанное иллюстрируется на рис. 11.8. Мы решили заранее нарисовать на фоновой битовой карте градиентную заливку фоновым цветом, вертикальные и горизонтальные линии и часть названия диаграммы. Было решено не включать в фоновое изображение следующие данные: собственно столбцы гистограммы, названия стран и их позиции на гистограмме, числовые метки для каждого деления на вертикальной шкале, текст над каждым из столбцов гистограммы и заполнение самих столбцов. Все эти объекты должны быть динамически сгенерированы во время выполнения приложения.

Рис. 11.8. Заблаговременно подготовленное фоновое изображение для гистограммы

Теперь нам предстоит принять очень важное решение относительно того, какому варианту отдать предпочтение: однократно прорисовывать фоновый битовый образ при каждом запуске приложения или же создать это изображение на стадии проектирования, скомпилировать в виде ресурса приложения и только загружать его на стадии выполнения. Если такое растровое изображение является статическим или необходимо иметь всего лишь несколько его различных вариантов, то, вероятно, имеет смысл подготовить их на настольном компьютере и включить в приложение как двоичный ресурс. Дополнительным преимуществом проведения такой подготовительной работы на стадии проектирования является то, что мы можем поручить ее профессиональному художнику-графику, который выполнит работу на высоком эстетическом уровне. Как бы то ни было, в любом случае мы сэкономим массу процессорного времени, поскольку каждый раз, когда будет требоваться повторная визуализация диаграммы, мы уже будем располагать ее заблаговременно подготовленной сложной частью, кэшированной для нужд приложения.

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

В соответствии с нашими планами относительно исходного варианта реализации мы могли бы нарисовать прямоугольники для каждого столбца и вывести над каждым из них соответствующий текст, но это было бы нерациональной тратой времени. Существует также проблема визуализации лишь части линий текста. Задача визуализации символов $$$ на 38 процентов высоты или символов €€€ на 76 процентов высоты средствами каркаса приложения может оказаться не столь уж простой. Учитывая сложность реализации этого подхода, от использования символов валюты можно было бы вообще отказаться, но это был бы позорный поступок с нашей стороны, поскольку наличие обозначений валюты на столбцах упрощает установление соответствия между странами и столбцами и поэтому снижает вероятность неправильного истолкования данных пользователем. Поэтому от всех этих "украшений" мы не отказываемся, но и платить за них лишнее не собираемся.