ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2016 г.)
2-летний импакт-фактор РИНЦ: 0,493
2-летний импакт-фактор РИНЦ без самоцитирования: 0,389
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,732
5-летний импакт-фактор РИНЦ: 0,364
5-летний импакт-фактор РИНЦ без самоцитирования: 0,303
Суммарное число цитирований журнала в РИНЦ: 5022
Пятилетний индекс Херфиндаля по цитирующим журналам: 355
Индекс Херфиндаля по организациям авторов: 499
Десятилетний индекс Хирша: 11
Место в общем рейтинге SCIENCE INDEX за 2016 год: 304
Место в рейтинге SCIENCE INDEX за 2016 год по тематике "Автоматика. Вычислительная техника": 11

Больше данных по публикационной активности нашего журнале за 2008-2016 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

1
Ожидается:
16 Марта 2018

Оптимизирующие стратегии визуализации данных в тактическом тренажере

Статья опубликована в выпуске журнала № 1 за 2009 год. [ на стр. 113 ][ 23.03.2009 ]
Аннотация:
Abstract:
Авторы: Новиков И.В. () - , , , Егоров А.И. () - , ,
Ключевые слова: паттерн «стратегия», пользовательский интерфейс, визуализация данных, тактический тренажер
Keywords: , user interface, data visualization, tactical trainer
Всего комментариев: 1
Количество просмотров: 6950
Версия для печати
Выпуск в формате PDF (3.60Мб)

Размер шрифта:       Шрифт:

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

Для эффективной визуализации ПРО в НИИ «Центрпрограммсистем» (г. Тверь) разрабатывается компонентно-ориентированная библиотека пользовательского интерфейса – IML UI (Interface modeling library for User Interface).

В концепции компонентной модели ПРО каждый моделируемый объект тактической обстановки может предоставлять пользовательский интерфейс, который характеризуется множеством элементов управления (ЭУ). Каждый ЭУ в IML UI определяется набором атрибутов (позиция, имя, идентификатор, текст, пользовательские данные) и совершаемых над ним операций. ЭУ образуют иерархию (дерево): каждый ЭУ создается в некотором другом элементе, называемом родительским. Взаимодействие между моделями тактического тренажера и ЭУ осуществляется путем последовательного выполнения предопределенных операций. Множество таких операций выполняются синхронно в каждый момент с определенным шагом. Эффективная реализация этих операций может существенно повысить производительность ПРО.

Рассмотрим основные операции, производимые над ЭУ, то есть определим интерфейс взаимодействия. Помимо базовых операций (получение интерфейсов, модификация основных атрибутов), введем дополнительные, список которых вместе с соответствующим методом программного интерфейса выглядит следующим образом:

1)  вычисление (оценка) размера ЭУ – EstimateSize;

2)  обновление расположения дочерних элементов – UpdateLayout;

3)  обновление части экрана (прямоугольника) – InvalidateCtrl;

4)  рисование ЭУ на физическом устройстве – DoPaint;

5)  поиск в дереве ЭУ по заданным значениям атрибутов – FindControl.

Кроме того, введем операции над контейнерными (содержащими дочерние элементы) ЭУ:

6)  добавление элемента – AddItem;

7)  получение элементов по индексу – GetItem;

8)  получение количества дочерних элементов – GetItemCount;

9)  удаление элементов из контейнера – RemoveItem и RemoveAll.

Каждый разрабатываемый ЭУ реализует базовые операции и при необходимости предоставляет дополнительные операции, оформленные по правилам IML в виде программного интерфейса.

Многие ЭУ имеют алгоритмически сложную реализацию рассмотренных операций (1–9), поэтому проектирование классов модуля IML UI основано на стратегиях [1], что позволяет создавать новые классы ЭУ со сложным поведением, используя множество небольших объектов (называемых стратегиями), каждый из которых отвечает только за один функциональный или структурный аспект (рис. 1). Функциональный аспект затрагивает определенный набор операций 1–9. Стратегии можно реализовывать по-разному, поскольку их интерфейсы полностью находятся в компетенции разработчика.

Особое внимание следует уделить операциям 1 и 2, которые выполняются при изменении размеров окна, так как технология динамического позиционирования ЭУ (dynamic layout) является неотъемлемой частью модуля IML UI. Необходимость разработки оптимизирующих стратегий обусловлена ресурсоемкостью этих операций. Рассмотрим стратегии рисования и стратегии обновления ЭУ при модификации данных.

Опишем возможные стратегии отрисовки ЭУ (реализация операций 1–4). Процесс начинается с того момента, как ОС Windows пошлет активному окну сообщение о необходимости перерисовки. Затем процедура обработки очереди сообщений (window proc) делегирует обработку сообщения объекту типа «стратегия рисования», который в свою очередь совершит операцию рисования DoPaint обходом дерева ЭУ в глубину. Для того чтобы предотвратить мерцание изображения на экране (image flickering), часто применяется техника двойной буферизации (double buffering) [2]. Данная техника требует дополнительного изображения в памяти, максимальный размер которого может достигать размера экрана. При хорошем разрешении (1 600´1 200 с глубиной цвета 32 бита) размер изображения будет превышать 7,5 Мб. Следовательно, техника дает преимущества только для небольших областей экрана, причем контролируемого размера.

Рис. 1. Реализация элемента управления на основе стратегий

Правильно подобранная стратегия помогает избежать перерасхода ресурсов памяти. Если контейнерный ЭУ нарисован на растровой области в памяти, то все его дочерние элементы тоже будут использовать этот разделяемый буфер. К тому же данный подход не требует операций очистки фона, так как эту процедуру автоматически могут выполнять контейнеры элементов непосредственно при рисовании, подготовив фон для своих дочерних элементов. Оптимизация на уровне ресурсов осуществляется сокращением количества используемых в каждый момент объектов ОС, таких как дескрипторы окон, контексты устройств и т.д. При возможности ресурсы ОС кэшируются объектом «стратегия», тем самым сокращая количество системных вызовов, эффективно применяя парадигмы «не создан, пока не востребован» и «освобожден только после выполнения всех операций» с помощью механизма подсчета ссылок [1].

При этом другая реализация поведения объекта «стратегия» может использовать или рисование напрямую на экран, или аппаратные возможности видеоконтроллера. Скажем, для отображения динамически изменяемого во времени процесса в системе имитационного моделирования возможна реализация стратегии рисования, использующая буфер кадров дисплея (display frame buffer).

В силу того что выбор стратегий зависит не только от типа и параметров ЭУ, в рамках IML UI реализован комплексный механизм выбора оптимизирующей стратегии визуализации, который после оценки значения атрибутов ЭУ (ширина, высота, частота обновления) принимает решение в зависимости от представленных на компьютере аппаратных средств.

Проектирование на основе стратегий может эффективно применяться и при создании контейнерных ЭУ (операции 6–9). Пользователь рассчитывает на то, что после добавления очередного элемента в контейнер происходит его обновление, то есть последовательное выполнение операций 2–4. Однако при добавлении целого множества из N элементов управления в одном цикле будет совершено N операций обновления, хотя требуется только одна. Разработка на основе стратегий позволяет выбрать политику обновления ЭУ при модификации данных.

В качестве примера возьмем элемент управления «Список» (ListControl), который является контейнерным, так как содержит дочерние компоненты – элементы списка. По умолчанию при добавлении очередного элемента в список генерируется событие перерисовки (аналогично в стандартных списках Windows). Предположим, нам необходимо каждую секунду добавлять 1 000 строк в список. В первом приближении можно организовать следующий цикл для объекта list (используется синтаксис в стиле C++ с учетом введенных операций, вызываемых через точку), выполняющий последовательно 1 000 операций:

for(i=0; i<1000; i++) {

list.AddItem(…);

}

Предполагая, что операция добавления элемента обновляет список, с ростом количества элементов в списке будет увеличиваться время выполнения всей задачи, в лучшем случае по линейному закону. Оптимизация заключается в достижении константного времени выполнения задачи. Для решения необходимо определить множественные (или групповые) операции как атомарные и не выполнять обновление элемента до окончания выполнения последней (1 000-й) операции. Чтобы сделать групповую операцию атомарной, введем 2 дополнительные операции над ЭУ: операцию перехода в режим модификации данных – BeginUpdate и операцию выхода из режима модификации данных – EndUpdate.

Выберем следующую простую стратегию обновления списка на основе блокировок (lock strategy). Сохраним счетчик выполняемых операций, начальное значение которого равно нулю (lock=0). При очередном вызове BeginUpdate счетчик ссылок увеличивается, а семантика операции EndUpdate будет следующей: если счетчик операций равен 0, то выполняем последовательно операции 2 и 3 (UpdateLayout и InvalidateCtrl). Выбранная стратегия реализует механизм отложенного выполнения операций обновления. Обновление происходит только после завершения последней операции EndUpdate.

// lock=0

list.BeginUpdate( lockStrategy ); // lock=1

for(i=0; i<1000; i++) {

list.AddItem(…); // обновление не происходит, так как

lock>0

}

list.EndUpdate(); // lock=0

Рис. 2. Стратегия группировки операций обновления экрана ПРО

Таким образом определена пользовательская операция добавления 1 000 элементов на основе стратегии со счетчиком обновлений в виде отдельной функции, в теле которой будут выполнены операции 1 и 2 всего один раз против тысячи. В зависимости от реализации списка получим различное время выполнения. Вычислительные эксперименты по оценке времени одной из реализаций списка представлены в таблице. При этом в результате применения оптимизирующей стратегии время на решение задачи было сокращено в 25 раз. Следует обратить внимание, что уже на пятой секунде время выполнения последовательных операций с обновлением превысило 1 секунду. Тем самым добавление очередной порции элементов на шестой секунде значительно превысит допустимое время выполнения, что может привести к снижению общей производительности. Таким образом, в системах моделирования, где критичным параметром становится время выполнения всех операций, выбор оптимизирующей стратегии является решающим фактором, определяющим эффективность визуализации.

Сравнительная оценка времени выполнения операций

Время, с

Выполнение операций последовательно, мс

Выполнение групповой операции, мс

Количество элементов в списке

0

-

-

0

1

288

26

1000

2

413

26

2000

3

629

26

3000

4

851

26

4000

5

1073

26

5000

Общее

3254

130

5000

Получив необходимый результат для отдельного ЭУ, последовательно сгруппируем операции обновления для достижения константного времени обновления экрана целиком (рис. 2).

Подобная оптимизирующая стратегия может быть разработана в силу того, что в контексте обновления можно выполнять поочередно операции, модифицирующие данные, представленные в ЭУ.

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

Список литературы

1. Andrei Alexandrescu. Modern C++ Design: Generic Programming and Design Patterns Applied. – Addison Wesley, 2001.

2. Jonathan Knudsen. Java 2D Graphics. – O`Reilly, 1999.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=2045
Версия для печати
Выпуск в формате PDF (3.60Мб)
Статья опубликована в выпуске журнала № 1 за 2009 год. [ на стр. 113 ] Версия для печати с комментариями

Возможно, Вас заинтересуют следующие статьи схожих тематик: