Первые планы по разработке GNOME Shell 4
14 ноября 2017 года
Разработчики GNOME начали публикацию идей по дальнейшему развитию рабочего стола и определили первые планы, касающиеся GNOME Shell 4. В качестве ключевой задачи называется уход от архитектурных ограничений GNOME Shell 3, который спроектирован для работы в роли композитного менеджера для X11 и завязан на особенности X11 при взаимодействии с GPU и устройствами ввода.
Например, за передачу событий ввода, высокопроизводительную отрисовку и перемещение курсора отвечал X-сервер, к которому приложения могли обратиться напрямую, в обход GNOME Shell. После появления Wayland положение в корне изменилось и ранее решаемые X-сервером задачи легли на плечи GNOME Shell, который теперь должен сам перенаправлять события ввода и транслировать вывод окон клиентов к GPU.
В связи с этим выделяется пять ключевых проблем, требующих доработки GNOME Shell: перенаправление событий ввода и клиентского контента (прямой вывод без двойной буферизации) с минимальными задержками, обеспечение оперативной реакции курсора в ответ на события ввода, поддержка методов ввода в Shell UI и избавление от влияния притормаживания в основном потоке на перерисовку кадров при композитинге контента приложений.
План подразумевает два варианта дальнейшего развития оболочки. Первый вариант предлагает разбить GNOME Shell на два отдельных процесса, отвечающих за интерфейс пользователя и композитинг. Ключевым звеном процесса композитинга станет библиотека Libmutter, предоставляющая несколько обработчиков, вынесенных в отдельные потоки. В том числе в отдельные потоки предлагается выделить код для взаимодействия с видеоподсистемой через интерфейс KMS (Kernel mode-setting), обработки ввода, поддержки Wayland и композитинга/управления окнами.
Процесс с интерфейсом пользователя предлагается полностью переписать, избавившись от применения тулкита St (Архивная копия от 6 марта 2021 на Wayback Machine) ( Shell Toolkit) в пользу штатного API GTK+. Для вывода предлагается использовать бэкенд GDK Wayland вместе с дополнительным расширением к протоколам Wayland, обеспечивающим интеграцию GNOME Shell с процессом композитинга. X-сервер полностью исключается из работы GNOME Shell - GNOME Shell будет оформлен как Wayland-клиент, всегда работающий через Wayland-бэкенд, даже когда обеспечивается работа сеансов X11.
Предложенная первым вариантом переработка решит все обозначенные проблемы, но для реализации задуманных архитектурных изменений потребует переписать с нуля значительную часть кода GNOME Shell, что приведёт к нарушению совместимостью с дополнениями и возможно необходимости их полной переработки. Для сглаживания разрыва совместимости с дополнениями рассматривается возможность развития GNOME Shell 4 до полной готовности в полностью отдельной ветке, поэтапный переход с постепенной заменой функциональности или назначение времени нарушения совместимости с постепенным переводом дополнений на новый API.
В качестве второго, щадящего, варианта называется применение прокси дисплейного сервера, который будет напоминать X-сервер и станет прослойкой, с которой могут взаимодействовать клиенты Wayland, транслирующей обращения к подсистемам KMS и libinput. При этом GNOME Shell напрямую не взаимодействует с KMS, а выполняет операции композитинга через данную прослойку. По сути прослойка будет выступать в роли полноценного сервера Wayland, что потребует полной реализации всех протоколов Wayland как в данной прослойке, так и в GNOME Shell.
Второй вариант требует существенно меньше трудозатрат и сохраняет совместимость с имеющимися дополнениями, но решает лишь первые 3 из 5 задач из списка намеченных проблем. Из положительных сторон отмечается не влияние крахов GNOME Shell на выполняемые в сеансе приложения, так как в случае подобных сбоев прослойка сохраняет состояние клиентских соединений. Из недостатков отмечается сохранение необходимости применения двух тулкитов (St и GTK+), не решаются проблемы с привязкой к методам ввода, требуется дублирование реализации протоколов Wayland (в прослойке и в GNOME Shell), а выполняемые через GNOME Shell операции отрисовки интерфейса пользователя по-прежнему могут приводить к задержкам операций отрисовки окон клиентов.
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
