Первые планы по разработке GNOME Shell 4

Автор denkin, ноября 15, 2017, 01:29:45

« предыдущая - следующая »

denkin

Разработчики GNOME начали публикацию идей по дальнейшему развитию рабочего стола и определили первые планы, касающиеся GNOME Shell 4. В качестве ключевой задачи называется уход от архитектурных ограничений GNOME Shell 3, который спроектирован для работы в роли композитного менеджера для X11 и завязан на особенности X11 при взаимодействии с GPU и устройствами ввода.
Новость на opennet
Подробности

"Например, за передачу событий ввода, высокопроизводительную отрисовку и перемещение курсора отвечал X-сервер, к которому приложения могли обратиться напрямую, в обход GNOME Shell. После появления Wayland положение в корне изменилось и ранее решаемые X-сервером задачи легли на плечи GNOME Shell, который теперь должен сам перенаправлять события ввода и транслировать вывод окон клиентов к GPU.

В связи с этим выделяется пять ключевых проблем, требующих доработки GNOME Shell: перенаправление событий ввода и клиентского контента (прямой вывод без двойной буферизации) с минимальными задержками, обеспечение оперативной реакции курсора в ответ на события ввода, поддержка методов ввода в Shell UI и избавление от влияния притормаживания в основном потоке на перерисовку кадров при композитинге контента приложений.

План подразумевает два варианта дальнейшего развития оболочки. Первый вариант предлагает разбить GNOME Shell на два отдельных процесса, отвечающих за интерфейс пользователя и композитинг. Ключевым звеном процесса композитинга станет библиотека Libmutter, предоставляющая несколько обработчиков, вынесенных в отдельные потоки. В том числе в отдельные потоки предлагается выделить код для взаимодействия с видеоподсистемой через интерфейс KMS (Kernel mode-setting), обработки ввода, поддержки Wayland и композитинга/управления окнами.

Процесс с интерфейсом пользователя предлагается полностью переписать, избавившись от применения тулкита St (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 операции отрисовки интерфейса пользователя по-прежнему могут приводить к задержкам операций отрисовки окон клиентов."
(с)

[свернуть]