International conference of developers
and users of free / open source software

Разработка модулей расширения для аппаратно-ускоренных графических оболочек на базе Compiz

Владмир Дёмин, Брест, Беларусь, spas.work@gmail.com

Рассмотрены особенности создания плагинов для менеджера окон Сompiz. Показаны различия в коде, особенности использования объектно-ориентированного языка для разработки compiz++. Оценены изменения, направленные на снижение порога вхождения новых разработчиков.

Современные аппаратно-ускоренные менеджеры окон (в т.ч. Compiz) используют возможности библиотеки OpenGL для передачи вычислительной нагрузки графическому акселератору. Одно из свойств OpenGL – объекты фреймбуфера – дает оконному менеджеру эффективный доступ к окнам приложений. Для приложения объекты фреймбуфера выглядят как обычные окна, а для использующего OpenGL оконного менеджера — как текстуры, которыми можно управлять помощью обычных команд отрисовки мультитекстур.

Благодаря экономному использованию памяти и аппаратному ускорению Compiz стал популярен среди пользователей и разработчиков. На сегодняшний день для него существует множество плагинов, улучшающих интерфейс, оптимизирующих рабочее пространство и просто украшающих рабочие столы Linux-систем.

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

На момент написания этой статьи, готовится к выходу следующая версия композитного менеджера Compiz, 0.9.x (Compiz++). Ее основные отличия от 0.8.x:

  • новый интерфейс для создания плагинов, более производительный, но несовместимый с плагинами, разработанными ранее;
  • разделение композитного (XComposite) и OpenGL уровней (в виде раздельных плагинов), что позволяет использовать Compiz как обычный оконный менеджер когда композитный режим недоступен;
  • переработанная система обработки текстур позволяет интегрировать несколько текстур на один pixmap;
  • система сборки CMake.

Изменения являются кардинальными, и открывают новые возможности для разработчиков плагинов. Новый API полностью переработан и значительно упрощен, CMake ускоряет процесс написания или корректировки конфигурации сборки, а переход на язык C++ делает код более понятным.

В процессе написания плагина для Compiz необходимо создать make-файл для сборки проекта, xml-файл для описания интерфейса управления плагином, файл plugin.info, содержащий список зависимостей разрабатываемого модуля к другим плагинам, и наконец – файлы исходного кода. Если для первых 3-х файлов особой разницы для разработчика плагина замечено не будет, то при написании кода самого плагина возникает ряд сложностей.

Основные проблемы разработки для текущей версии Compiz связаны со слабой документированностью функций его API. Единственным способом для написания собственного плагина остается разработка на основе готового решения. В свою очередь этот подход имеет следующие недостатки:

  • код плагинов также слабо документирован и зачастую плохо структурирован, что отнюдь не облегчает его понимание;
  • при желании добавить какой-либо функционал приходится затрачивать много времени на поиск соответствующей функции ядра и изучение её поведения.

Перечисленные недостатки были лично прочувствованы автором при работе над плагином рабочего пространства с миниатюаризацией окон, и их можно наблюдать воочию в коде проекта по адресу http://www.github.com/spasmus/mWin .

При разработке новой версии Compiz эти недостатки были в значительной степени учтены, и в первую очередь – переходом на язык с объектно-ориентированной парадигмой – C++. Очевидно, для описания интерфейсов и отрисовки на экране это более подходящее решение, благодаря которому разработчик может начать создавать новые и модифицировать существующие плагины без необходимости чтения несуществующих руководств. Также было принято решение переложить проблему с документацией на приложение Doxygen, и уже в новой версии 0.9.x имеется описание всего API ядра. Конечно, автоматических средств ведения документации недостаточно, поэтому в настоящее время многое добавляется самими разработчиками ядра.

Для наглядной оценки изменения степени сложности в разработке плагинов, были написаны и проанализированы простейшие плагины для обеих версий. При переходе от compiz к compiz++ замечено уменьшение исходного кода в среднем на 15-20%, вдобавок к этому код становится более простым для понимания. В частности, исключаются макросы-обертки для вызова родительского обработчика, а также макросы для получения объектов дисплея, экрана и окна, значительно ухудшавшие читабельность кода. Пример фрагментов одного и того же кода для разных версий Compiz приведен в таблице:

Несмотря на очевидные плюсы, есть и проблемные стороны перехода:

  • необходимость портирования кода фактически на другой язык программирования, и, как следствие, появление новых ошибок, потеря большого количества времени разработки;
  • неизвестно, насколько может упасть производительность работы системы в целом несмотря на заявленные более производительные решения;
    вероятен отток чистых Си-программистов из проекта.

Материалы к докладу