Средства разработки графического по для БагрОс-4000
Разработка прикладных программ для устройств на основе БагрОС-4000 предполагает использование 2-х ЭВМ.
Одна из них выполняет функции инструментальной машины с различными инструментами разработчика – средствами написания программного кода, отладки независящих от ОС частей разрабатываемой программы, а также пакетом кросс-разработки, обеспечивающим компиляцию модулей разрабатываемой прикладной программы и выполняющим создание загружаемого образа дистрибутива БагрОС-4000 с включением в него файлов прикладной программы.
Упомянутый пакет кросс-разработки требует, чтобы на инструментальной машине был установлен дистрибутив ОС Linux, основанный на rpm или deb пакетах.
Вторая машина является целевым вычислителем, на который загружаются собранные с помощью пакета кросс-разработки образы ОС с добавленными туда файлами прикладной программы. В данном проекте целевым вычислителем является компьютер на архитектуре Эльбрус – «Эльбрус 401» компании МЦСТ.
Исходя из вышесказанного, процесс разработки прикладных программ для БагрОС-4000 можно представить в следующем виде (рисунок 1.1):
Рисунок 1.1 – Процесс разработки программ для БагрОС-4000
Из-за особенностей пакета кросс-разработки единственным языком, с помощью которого есть возможность вести разработку, является язык Си стандарта C99[ CITATION Кер15 \l 1049 ]. А также, с точки зрения разработки именно графических приложений, большая ограниченность низкоуровневых библиотек: на данный момент доступна только реализация стандарта OpenGL SC (Safety-Critical) 1.0.1 и библиотека FreeType2[ CITATION The20 \l 1033 ] для работы с векторными шрифтами.
Более высокоуровневых библиотек, в значительной мере упрощающих разработку графических приложений для популярных ОС (Windows, Linux), для БагрОС-4000 нет совсем.
Отрисовка кадра с помощью OpenGl
OpenGL работает по принципу конвейера, этапы работы которого можно описать следующим образом:
Формирование последовательности команд и данных в буфере на стороне клиента путём вызова методов и функций API.
Отправка данных из клиентского буфера на видеокарту. Может происходить автоматически вследствие заполнения буфера либо путём вызова одного из методов:
glFlush() – отправка данных на ГП без блокировки работы с буфером
glFinish() – отправка данных на ГП с блокировкой работы с буфером до окончания обработки данных аппаратной частью
Наглядно различие между этими двумя методами показано на рисунке 1.2.
Рисунок 1.2 – Разница между glFlush и glFinish
Выполнение видеокартой полученных команд с полученными данными (позиционирование точек и полигонов, наложение текстур, постобработка и т. д.).
Вывод полученного изображения в буфер кадров для последующего вывода его на экран.
Однако, в современной практике использование glFlush и glFinish считается устаревшим. Вместо них используется двойная и тройная буферизация кадров. Данные методы требуют гораздо большего количества ресурсов вычислительного комплекса, однако позволяют избежать наблюдаемых пользователем «артефактов», появляющихся из-за непостоянности скорости построения кадра.
Проблема использования всего одного (экранного) буфера состоит в том, что рисование непосредственно в него может происходить гораздо быстрее, чем частота обновления изображения экраном, из-за чего пользователь может наблюдать так называемые разрывы экрана (англ. screen tearing). Пример подобного эффекта приведён на рисунке 1.3.
Рисунок 1.3 – Пример разрыва экрана
Проявляется это в случае, когда видеокарта отрисовывает больше кадров в секунду, чем монитор. В результате видеокарта начинает рисовать новый кадр до того, как монитор отобразил предыдущий.
Двойная буферизация позволяет избежать подобных искажений путём использования дополнительного (заднего) буфера, в который происходит отрисовка кадров видеокартой. Как только монитор закончит с отрисовкой предыдущего кадра, содержимое этого буфера помещается в экранный буфер, а видеокарта начинает отрисовку следующего кадра в освободившееся место. С технической точки зрения это обычно реализовано сменой указателей на экранный и задний буферы местами.
Однако и этот способ не лишён недостатков. Он хорошо работает только в случае, когда скорость отрисовки кадров видеокартой значительно больше, чем у экрана. Если же они близки или, наоборот, скорость видеокарты ниже скорости монитора, периодически могут возникать ситуации, когда монитор отрисовал кадр, а видеокарта – нет. В этом случае на экране будет снова выведен старый кадр, даже если видеокарта практически закончила отрисовку в задний буфер. Это может вызвать довольно заметные подтормаживания изображения, особенно раздражающие в активных сценах.
Данный недостаток двойной буферизации и призвана исправить тройная буферизация. При добавлении третьего буфера (дополнительного), если видеокарта быстрее отрисовала кадр в задний буфер, нет необходимости ждать, пока закончится отрисовка экранного буфера монитором. Можно начать отрисовку следующего кадра в дополнительный буфер. В итоге, мы в большинстве случаев избегаем ситуаций, когда закончена отрисовка экранного буфера монитором, а видеокарта ещё не закончила отрисовку в задний буфер.
Безусловно, в случае, когда скорость отрисовки кадров видеокартой гораздо выше, эффекта от тройной буферизации, по сравнению с двойной, не будет.
Возможность использования двойной и тройной буферизации зависит от ресурсов и возможностей аппаратного обеспечения, из-за чего и их использование в OpenGL зависит от конкретного аппаратного обеспечения. Вследствие чего, для сохранения кроссплатформенности непосредственно OpenGL-кода, работа с буферами, как и создание окон, происходит с помощью сторонних библиотек, таких как, к примеру, GLFW или GLUT.