Разработчик X.Org рассказал о перспективах проекта Wayland
Дэниэл Стон (Daniel Stone), бывший член совета директоров X.Org Foundation, отвечающий за разработку XKB и являющийся одним из инициаторов перехода X.Org на модульную структуру, в настоящее время подключившийся к разработке проекта Wayland, выступил на конференции Linux.conf.au с большим докладом (видеозапись), посвящённым анализу недостатков X.Org и рассмотрению методов ухода от данных проблем в Wayland. В докладе указывается, что несмотря на то, что поддержка Wayland в десктоп-окружениях и приложениях ещё только зарождается, Wayland более перспективен для применения в будущем.По мнению Дэниэла, некоторые внутренние механизмы X11 ужасны и до абсурда усложнены. X11 оброс огромным числом расширений, пытающимися добавить в протокол X11 возможности, на которые он изначально не был рассчитан (вывод видео, OpenGL, подключение нескольких устройств ввода и вывода и т.п.). Для преодоления проблем с X-сервером многие вещи приходится реализовывать силами X-клиентов (шрифты, визуальные эффекты, нетривиальные декорации, темы оформление, управление окнами и т.п.).
Реалии таковы, что клиент сам выполняет рендеринг своих окон и отдаёт X-серверу готовый результат, для компоновки которого сервер обращается к оконному менеджеру, получает от него результат рендеринга содержимого экрана и просто выводит уже готовое изображение. В результате оконный менеджер превращается по сути во второй X-сервер, оставляя изначальному X-серверу только функции посредника. Wayland предлагает избавиться от лишних прослоек и предлагает новую модель, при которой клиент отрисовывает содержимое своих окон локально и передаёт готовый битмап серверу, который сам решает, что и где вывести на экран с учётом таких особенностей, как перекрытие окон и прозрачность.
Что касается обеспечения сетевой прозрачности, то X уже не может похвастаться данной особенностью в контексте выполнения современных приложений, так как многие надстройки для обеспечения работы пользовательских интерфейсов неработоспособны по сети (например, SHM и DRI2 не работают поверх сети, в программах обычно используется D-Bus, API нотификации и различные графические тулкиты, работающие с видеоподсистемой напрямую). Метод обеспечения удалённого взаимодействия с рабочим столом, основанный на идее передачи по сети в сжатом виде уже отрисованных окон, выглядит более адекватным и соответствующим современным реалиям, чем давно устаревший подход X.
По сравнению с другими платформами, предлагаемые X-сервером методы называются дилетантскими, с позиции предоставления средств для комфортной работы пользователя. Дэниэл поясняет, что хотя X-сервер уже не является столь важным звеном, клиенты продолжают активно взаимодействовать с ним, даже без явной на то причины, что приводит к дополнительным задержкам. Результаты измерения показали, что при открытии Chrome подобные задержки составляют примерно полсекунды. При определённом стечении обстоятельство при выполнении Gedit удалось зафиксировать задержку в 1.4 сек (130 блокирующих вызовов InternAtom, 34 - GetProperty и 116 запросов на изменение свойств).
Дополнительно, можно отметить серию публикаций Мартина Грэслина (Martin Gräßlin), занимающегося интеграцией поддержки Wayland в оконный менеджер KWin. В отличие от эталонного композитного сервера Weston, практикующего создание декорации окон на стороне клиента (силами графических фреймворков), в KWin предлагается осуществить декорацию на стороне композитного сервера, когда организация оформления окон унифицирована и реализуется независимо от выполняемого приложения.
Проконсультировавшись с разработчиками Qt Мартин пришёл к выводу, что что перенос декорации на сторону сервера позволит повысить производительность, так как реализация данной функции на стороне Qt приводит к излишней паразитной нагрузке и разработчики Qt уже предусмотрели опцию для отключения данного режима. Кроме того, декорация окон на стороне сервера позволит адаптивно менять интерфейс для различных классов устройств, таких как нетбуки и планшеты.
Полный текст статьи читайте на OpenNet
