С 23 по 25 сентября проводилась очередная X Developers Conference, XDC2013. На ней было несколько докладов, полезных для широкой публики — и одним из них был доклад о XMir и XWayland. Автор — Chris Halse Rogers из компании Canonical, ранее занимавшийся сопровождением X-сервера в убунту и теперь привлечённый к разработке Mir и XMir. Здесь будет изложен краткий конспект этого доклада, взятый из PDF-слайдов и видеозаписи.
Прежде чем рассказывать про вложенные X-серверы внутри Mir и Wayland, следует рассказать о Mir — ведь на данный момент немногие подробно изучили его кодовую базу. Mir — это
- Библиотека для создания сущностей, выполняющих задачи дисплейного сервера, композитора окон и оболочки рабочего стола
- Библиотека для взаимодействия с созданными сущностями со стороны прикладного ПО
- И примерно 90 тысяч LoC (осмысленных строк кода) на C++, включая заголовки и тесты. Тесты составляют половину общего числа LoC.
Дизайн Mir имеет отличия от дизайна Wayland
- Это библиотечный API, а не межпроцессный протокол или механизм
- Буферы цвета для окон создаются на стороне сервера (прим. — в трёхмерной графике есть множество других буферов, хрянящих не цветовые значения пикселей — потому и возникло понятие color buffers). Приложение получает буфер цвета на время рисования кадра и затем отдаёт его обратно в обмен на другой буфер, а владеет этими буферами сам Mir.
Цели, к которым идёт Mir, также отличаются. Wayland стремится быть полезным для всех, например, над ним активно работают разработчики Tizen и сообщество вокруг Rasberry Pi. В то же время Mir создан для достижения задач Canonical — но, как надеются его разработчики, может пригодиться и для решения более общих задач. Mir нацелен на улучшение работы Unity.
После этой части доклада Крису задали несколько вопросов, в том числе — о буферах цвета на стороне сервера. Wayland может сам владеть буферами и выдавать их приложениям по запросу, а может использовать буферы, переданные клиентом — в чём тогда различие между Wayland и Mir в управлении буферами цвета? Дело в том, что Rasberry Pi и все мобильные операционные системы стремятся передать владение буферами дисплейному серверу, потому что это позволяет забирать буферы у неактивных (suspended) приложений и тем самым получать серьёзную экономию памяти. Однако mesa оперирует только клиентскими буферами, и поэтому на десктопном компьютере не получится просто так получить буфер, которым владеет дисплейный сервер. Кроме того, разработчики тулкитов и приложений по сути могут сделать выбор так, как им захочется, ограничившись только одним из двух режимов работы wayland. (прим. — Крис вроде бы упоминал о способе обойти это с помощью «wayland shared buffer extension», но я не понял, о чём именно идёт речь).
Как XMir, так и XWayland запускают вложенный X-сервер, используя механизм расширений Xfree86. Через этот механизм обеспечивается вывод графики средствами Mir и Wayland, передача событий ввода X-серверу, drag&drop, управление окнами и остальные вещи, нужные для полноценной работы иксов. Когда Mir и Wayland встраиваются во вложенный X-сервер, они диктуют ему следующее:
- Пожалуйста, не трогай реальный дисплей
- Возьми буферы цвета
- Дай нам реализовать RANDR самим
- И несколько более сложным образом реализуется работа GLX
Есть различия в организации передачи изображения на реальный дисплей. Wayland для каждого окна использующего X приложения запускает отдельный вложенный X-сервер, и благодаря этому основанный на Wayland композитор захватывает буфер цвета окна (которым владеет X). Mir сам владеет всеми буферами цвета и к тому же всегда использует как минимум двойную буферизацию (т.е. для передачи изображения на дисплей обязательно придётся делать операцию swap buffers), поэтому он не может использовать аналогичный подход: ведь иксовые приложения, не использующие XGL, имеют один буфер и на каждом кадре просто рисуют нечто новое поверх старого. Поэтому Mir имеет два дополнительных буфера, эмулирующих двойную буферизацию — и на каждом кадре он отслеживает изменения, которые были сделаны в единственном буфере X-сервера, и копирует изменённые области в свой активный буфер; затем он делает swapBuffers.
Как показывают тесты Phoronix, подход Mir не приводит к существенному падению или увеличению производительности. Если рассматривать мелкие различия, то XMir работает чуть быстрее стандартного X-сервера на обычном многооконном десктопе в сочетании с композитным менеджером окна, и чуть медленнее — в полноэкранных играх. Замедление в полноэкранных играх, в свою очередь, можно исправить — ведь сам по себе XGL использует двойную буферизацию, как и Mir, и не нуждается в отслеживании и копировании изменённых областей. Единственным исключением из этих правил является KDE, работа которого чуть замедляется как на многооконном десктопе, так и в полноэкранных играх — дело в том, что оконный менеджер kwin сам по себе отслеживает изменённые области экрана и копирует только их; этот механизм используется в нём уже несколько лет. Это также объясняет, почему разработчики Kubuntu не хотят использовать XMir в Ubuntu 13.10 и 14.04.
Несмотря на различия в XWayland и XMir, часть кода может быть переиспользована в обоих проектах:
- Для вложенного X-сервера с системой ускорения GLAMOR иксовый видеодрайвер может быть написан один раз и использоваться в обоих проектах, и такой драйвер уже написан в рамках Wayland.
- Прокси для оконного менеджера (это не очень-то нужно для XWayland, который держит отдельный X-сервер для каждого окна, но полезно для XMir)
- И, возможно, libxcwm — библиотеку, позволяющую запускать иксовые приложения на системах, где вообще нет X-сервера, таких как Mac OS X, Windows, Wayland и Mir. Подробнее...
Иксовый драйвер ввода не получится переиспользовать, потому что модели обработки ввода в Mir и Wayland сильно различаются между собой.
После этого опять был перерыв на вопросы, и выяснилось, что подход XWayland (отдельный сервер на каждое окно) не только позволяет убрать прокси для оконного менеджера, но и делает управление окнами гораздо более простой задачей: поскольку каждое окно для Wayland представляет собой отдельный буфер, то композитор (он же оконный менеджер, в терминологии Wayland) может легко трансформировать окна по отдельности, и попытка сделать эффект волшебной лампы для сворачивающегося окна не приведёт к труднейшей задаче разделения окон, рисующих в один буфер одного X-сервера. С другой стороны, некоторые приложения начинают работать неправильно, если конфигурация предоставленного им X-сервера не соответствует реальной конфигурации мониторов, или если они не могут изменять конфигурацию мониторов, такую как разрешение экрана; в XMir такие приложения будут работать корректно.
