С момента заключительной статьи в первом большом теоретическом цикле прошло более месяца. За это время успел выйти новый релиз популярного дистрибутива Linux Ubuntu версии 9.10. Приятно отметить, что менеджер дисплея GDM в новом выпуске ведёт себя именно так как было нами описано в предыдущей статье "Немного реализма". Т.е. опция выбора окружения рабочего стола появляется только после ввода имени пользователя, и по умолчанию это всегда -- предыдущий выбор. Конечно, нельзя сказать, что такое изменение поведения было нами предсказано - на момент написания статьи, наверняка оно уже произошло в разрабатываемой версии дистрибутива. Однако, это хорошо показывает, что наши статьи говорят не о выдуманных проблемах современных интерфейсов, а о совершенно насущных. Статьи проекта unDE рассказывают о тенденциях развития не какого-либо неземного интерфейса или интерфейса далёкого будущего, а о самом что ни на есть настоящем, современном интерфейсе компьютерных систем.

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

В этой статье мы немного поговорим об архитектуре видеоподсистемы unDE. Т.е. о системе и способах прорисовки элементов интерфейса на экране. Мы снова постараемся поймать одну из последних волн развития современных интерфейсов -- они всё более начинают использовать возможности видеокарт для прорисовки интерфейсов. Windows версий Vista и Seven, KDE 4 практически уже не работают на компьютерах начала века, они в прямом смысле "ползают" на них. У нас есть выбор основать нашу систему прорисовки на принципах KDE 4, написав свой оконный менеджер с возможностями Compiz, либо предложить свой вариант. Стоит отметить, что интерфейсы для построения ускоренных приложений для графического сервера X Server пока не являются устоявшимися и стандартизованными. Об этом говорит в частности тот факт, что нет терминала, в котором одинаково хорошо работала бы прозрачность (реальная, а не псевдо) фона как в окружении KDE 4, так и окружении Gnome и в другом оконном менеджере.

В качестве ядра прорисовки мы постараемся использовать игровой движок 3D-редактора Blender. Для оценки его возможностей стоит немного поиграть в игру "Yo Frankie!" написанную его сообществом в 2008 году. На моей машине с процессором Pentium 4 1,7 GHz и видеокартой GE Force 4 MX 440 эта игра бегает достаточно шустро на глаз. В числах это быстродействие оказывается скоростью прорисовки около 20 кадров в секунду, падая на более сложных сценах до 8 кадров в секунду. Можно быть уверенным, что для абсолютного большинства задач нам не будет необходимости в прорисовке сцен сложностью хотя бы 20% от подобных игровых сцен. А значит наша система будет работать тем более быстро, особенно на современных машинах. При этом в сцены будет легко вставить любые 3D-эффекты или 3D-анимационных героев.

Помимо настольных машин нас также может волновать работоспособность на популярных теперь нетбуках. Судьба сложилась таким образом, что как раз недавно я приобрёл такой нетбук фирмы Dell модели Inspiron 1010 с видео-чипсетом от Intel GMA 500. Чипсет этот был выпущен в производство относительно недавно и драйвера для него находятся в активной разработке. На данный момент последние драйвера от 8 октября 2009 года всё ещё очень плохо работают с OpenGL, при том, что DirectX приложения могут летать. Например, SuperTux при включенном OpenGL начинает ползать, а при отключенном ускорении -- работает прекрасно! Говорить о какой-либо удовлетворительной производительности такой игры как  "Yo Frankie!" тут вовсе не приходится. Конечно, кто-то может сказать, что виноваты не драйверы, а сам чипсет, но я возражу, что есть сторонний драйвер от Next Generation Coders, с которым  и SuperTux в режиме openGL не тормозит (правда при переключении экран становится чёрным, но это исправляется переключением в любое другое приложение и возвращение обратно), и в "Yo Frankie!" в начальной заставке птичка хорошо летает. К сожалению дальше быстродействие заценить не удалось, так как после выбора меню опции, игра выдала недопуcтимую операцию с памятью и была закрыта. А при перезапусках выдавала её тут же. После нескольких попыток перезапуска Windows вовсе показала синий экран смерти. Таким образом к сожалению эти сторонние драйвера ещё тоже далеки от стабильного состояния, но однозначно способны выжать из чипсета GMA 500 больше.

Использование игрового движка Blender для прорисовки позволит нам во-первых создать кроссплатформенную систему. В отличие от того же KDE 4, которая кроссплатформенна лишь на уровне отдельных приложений.

Важно понимать, что unDE таким образом сможет запускаться в современных системах как обыкновенное оконное приложение. Это будет особенно удобно на начальных этапах разработки, пока в unDE нельзя будет выполнять все задачи необходимые большинству пользователей. unDE сможет использоваться на начальных этапах как только текстовый редактор или только графический редактор и т.д. По мере развития unDE сможет заменить всё большее число приложений, пока наконец его нельзя будет запускать как единственное приложение на X Server'е или в Windows-среде. Помимо запуска unDE в других средах вполне возможна реализация и обратного -- запуска X-приложений в среде unDE. Для этого необходимо реализовать внутри нашей системы протокол X-сервера. Однако это долгосрочные планы, а одним из первых нами будет реализован виртуальный терминал для запуска в unDE любых консольных приложений Unix-среды.

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

Одной из любопытных особенностей архитектуры Blender является бинарный формат его файлов. Каждый blend-файл содержит ДНК структур. ДНК содержит имена всех полей, всех структур используемых в нём, их размеры и типы. При загрузке Blender, зная собственную ДНК и ДНК файла, может легко распознавать такие модификации структуры как изменения порядка полей, изменения их размера (например, 16 бит на 32 бита) или типа (например, с float на integer и наоборот). Благодаря этому Blender может с лёгкость открывать файлы записанные версией 10-летней давности или наоборот версией гораздо более новой чем установленная на вашем компьютере.

Так как мы предполагаем использовать бинарный формат в unDE (BerkeleyDB), то вполне возможно взять на вооружение подобный подход и записывать ДНК каждого файла в одну из первых записей базы данных.

Первичное исследование кода Blender показало, что желательно всё же в достаточной мере изучить Blender снаружи, чтобы иметь представление о том, что из себя представляют такие объекты как текстуры, материалы, лампы, полигональные сетки, каркас и др.

Сейчас по Blender появилось гораздо больше документации, чем каких-нибудь 5 лет назад. Сообщество его расширилось, а потому изучение нами всех его тайн стало гораздо проще.

Мы начали с прочтения вики-книги "Blender 3D: Noob to Pro" и в первую очередь нам удалось создать следующие 3D-модели (изображения этих моделей распределены по статье равномерно):

Интерфейс Blender весьма оригинален в сравнении с большинством современных приложений. Однако, в нём сильно чувствуется слишком большое количество возможностей сделать одно и тоже множеством способом. Раз unDE будет основан на кодовой базе Blender, то вполне вероятно вскоре унаследует большинство его функциональности, а это не только 3D-редактор, но и по-меньшей мере мощный видео-редактор. Но интерфейс будет существенно переработан под общие каноны unDE.

На этом наше первое знакомство с Blender закончено. В следующих статьях мы постараемся в общих словах описать особенности его архитектуры.