История изменений

Продолжу. Итак, оконная подсистема и композитор.

Абстракция окна служит нескольким целям: interclient communication (ICC), логическая организация пользовательского интерфейса, физическая организация пользовательского интерфейса. Подробнее:

• С точки зрения взаимодействия производных клиентов: клиентам нужен механизм ICC. Поэтому окно является основным объектом для работы ICC. Клиенты могут отправлять окнам сообщения, устанавливать и получать значения произвольных свойств, подписываться на получение сообщений от окон и т.п. Тот механизм ICC, который имеется в X11, сделан в достаточной мере хорошо. Его имеет смысл взять за основу. (Возможно, с некоторым расширением фич.)
• С точки зрения оконного менеджера: WM служит для логического («смыслового») управления элементами пользовательского интерфейса. Поэтому требуется возможность организовывать окна иерархически.
• С точки зрения композитного менеджера: CM служит для диспетчеризации ввода между клиентами и для «сборки» итогового изображения, т.е. для «физического» управления элементами интерфейса. Для CM можно использовать либо ту же иерархию, что и для WM, либо реализовывать собственную («вручную», да).
• С точки зрения возможности встраивания одного агента в графический интерфейс другого агента. Одно приложение может захотеть управлять интерфейсом другого приложения — логически и/или физически — т.е. выполнять функции WM или CM. Поэтому понятия WM и CM следует рассматривать не как специальные приложения или часть сервера (привет вейланду), а как роли, которые может на себя взять любой клиент по отношению к любому другому клиенту. Сервер должен быть так спроектирован, чтобы этому просто не мешать. (Снова привет вейланду.)

Про ICC я писать не буду, в первом приближении можно считать, что оно принципиально не отличается от используемого в X11.

Иерархия окон:

Каждый экран имеет корневое окно (root window).
Каждое окно может иметь произвольное число дочерних окон. Каждое окно имеет ровно одного родителя (кроме корневого окна, не имеющего родителя).
При уничтожении окна уничтожаются все дочерние окна. (TODO: возможно, требует доработки в рамках работы над сессионностью.)
Иерархию можно произвольно модифицировать, т.е. переносить окно от одного родителя к другому.
Каждое окно имеет координаты (относительно родительского окна) и размер.
Каждое окно имеет z-координату для упорядочивания всех окон с общим родителем в стек.

Таким образом, логическая иерархия окон также не отличается принципиально от используемой в X11.

Прикладной «смысл» оконной иерархии лежит за пределами спецификации Xnext. (Даём механизм, а не политику.) Управление верхнеуровневыми окнами приложений должно быть описано в отдельном стандарте, разработанном на основе NETWM.

Рендеринг, комозитинг:

У окна имеются аттрибуты color-canvas, mask-canvas и sensitivity-canvas, содержащие идентификаторы поверхностей.
color-canvas хранит значения RGBA пикселей окна.
mask-canvas хранит маску, определяющую изменяется ли данный пиксель при наложении изображения дочерних окон.
sensitivity-canvas хранит битовый признак для каждого пикселя, определяющий чувствительность окна к событиям ввода.

Если у окна color-canvas не установлен (равен none), композитный менеджер должен обрабатывать это так, будто все пиксели color-canvas полностью прозрачны.
Если у окна mask-canvas не установлен (равен none), композитный менеджер должен обрабатывать это так, будто все фрагменты mask-canvas равны единице.
Если у окна sensitivity-canvas не установлен (равен none), композитный менеджер должен обрабатывать это так, будто все фрагменты sensitivity-canvas равны единице.

Если размеры color-canvas, mask-canvas или sensitivity-canvas не совпадают с размерами окна, результат рендеринга такого окна не определен.

У окна имеется аттрибут blending-mode, указывающий, как при рендеринге следует интепретировать альфа-канал полотна color-canvas. Значения: const — альфа-канал полотна color-canvas без изменений попадает в альфа-канал результирующего полотна; layered — color-canvas обрабатывается по тому же алгоритму, что и полотна дочерних окон.

У окна имеется булев аттрибут mapped, указывающий, учитывается ли окно в рендеринге вывода и обработке ввода.
У окна имеется булев аттрибут visible, указывающий, следует ли клиенту, отвечающему за это окно, обновлять его содержимое.

Композитный менеджер выполняет в оконной подсистеме две связанные функции:

• Осуществляет рендеринг иерархии окон для получения результирующего полотна (пригодного для вывода на экран или дальнейшей обработки).
• Осуществляет диспетчерезацию событий ввода от устройств позиционирования вглубь иерархии.

У каждого окна есть аттрибут target-canvas, который указывает на полотно, содержащее результат рендеринга данного окна композитным менеджером. Любой клиент может запросить значение target-canvas, чтобы «видеть», как «выглядит» «готовое» окно. Обычно это требуется композитному менеджеру родительского окна для наложения изображения дочерних окон, но не ограничивается этим. Другие возможные применения: утилиты для снятия скриншотов, отображение превью окон в различных утилитах управления окнами и т.п.

Пусть клиент C желает выступить композитным менеджером для окна W. Для этого он подписывается на событие composite-render данного окна. Одновременно только один клиент может быть подписан на событие composite-render, таким образом у окна может быть только один композитный менеджер. Если на это событие уже был подписан другой клиент, ему отправляется сообщение composite-render, и после этого он сразу теряет подписку на это сообщение. Если ни один клиент не подписан на composite-render, рендеринг данного окна осуществляется встроенным композитным менеджером.

Композитный менеджер обязан своевременно обновлять target-canvas. Для этого он должен подписаться на все события окна W и его дочерних окон, сообщающих о изменениях состояния, после которых требуется обновить результирующий вид окна.

По аналогии с composite-render, существует событие composite-input для регистрации клиента как менеджера, отвечающего за диспетчерезацию событий от устройств позиционирования. Если на composite-input не подписан ни один клиент, диспетчерезацию выполняет встроенный композитный менеджер.

Когда серверу требуется доставить событие от устройства позиционирования, он посылает клиенту, который подписан на composite-input, сообщение composite-input-pointer-state. Клиент обязан определить путь «прохождения» сообщения по его дочерним окнам и ответить одним из следующих запросов:

• composite-input-pointer-state-dispath-list. Если сообщение «попадает» в дочерние окна, клиент отсылает запрос composite-input-pointer-state-dispath-list, который содержит исходное событие и упорядоченный по «высоте» список дочерних окон, которые «задевает» данное сообщение, а также координаты точки «задевания» для каждого дочернего окна. Сервер попробует диспетчеризировать сообщение каждому из указанных окон. Если все они вернут composite-input-pointer-state-dispath-down, событие pointer-state будет отослано «данному» окну.
• (снова) composite-input-pointer-state-dispath-list. Если сообщение не «задевает» ни одного дочернего окна, но задевает «данное» окно, клиент отсылает запрос composite-input-pointer-state-dispath-list с пустым списком окон. После этого сервер отошлет «данному» окну событие pointer-state.
• composite-input-pointer-state-dispath-down. Если событие прошло «насквозь», не задев ни дочерние окна, ни поверхность «данного» окна, клиент отсылает запрос composite-input-pointer-state-dispath-down для диспетчеризации события дальше «вниз» по z-координате.

Продолжу. Итак, оконная подсистема и композитор.

Абстракция окна служит нескольким целям: interclient communication (ICC), логическая организация пользовательского интерфейса, физическая организация пользовательского интерфейса. Подробнее:

• С точки зрения взаимодействия производных клиентов: клиентам нужен механизм ICC. Поэтому окно является основным объектом для работы ICC. Клиенты могут отправлять окнам сообщения, устанавливать и получать значения произвольных свойств, подписываться на получение сообщений от окон и т.п. Тот механизм ICC, который имеется в X11, сделан в достаточной мере хорошо. Его имеет смысл взять за основу. (Возможно, с некоторым расширением фич.)
• С точки зрения оконного менеджера: WM служит для логического («смыслового») управления элементами пользовательского интерфейса. Поэтому требуется возможность организовывать окна иерархически.
• С точки зрения композитного менеджера: CM служит для диспетчеризации ввода между клиентами и для «сборки» итогового изображения, т.е. для «физического» управления элементами интерфейса. Для CM можно использовать либо ту же иерархию, что и для WM, либо реализовывать собственную («вручную», да).
• С точки зрения возможности встраивания одного агента в графический интерфейс другого агента. Одно приложение может захотеть управлять интерфейсом другого приложения — логически и/или физически — т.е. выполнять функции WM или CM. Поэтому понятия WM и CM следует рассматривать не как специальные приложения или часть сервера (привет вейланду), а как роли, которые может на себя взять любой клиент по отношению к любому другому клиенту. Сервер должен быть так спроектирован, чтобы этому просто не мешать. (Снова привет вейланду.)

Про ICC я писать не буду, в первом приближении можно считать, что оно принципиально не отличается от используемого в X11.

Иерархия окон:

Каждый экран имеет корневое окно (root window).
Каждое окно может иметь произвольное число дочерних окон. Каждое окно имеет ровно одного родителя (кроме корневого окна, не имеющего родителя).
При уничтожении окна уничтожаются все дочерние окна. (TODO: возможно, требует доработки в рамках работы над сессионностью.)
Иерархию можно произвольно модифицировать, т.е. переносить окно от одного родителя к другому.
Каждое окно имеет координаты (относительно родительского окна) и размер.
Каждое окно имеет z-координату для упорядочивания всех окон с общим родителем в стек.

Таким образом, логическая иерархия окон также не отличается принципиально от используемой в X11.

Прикладной «смысл» оконной иерархии лежит за пределами спецификации Xnext. (Даём механизм, а не политику.) Управление верхнеуровневыми окнами приложений должно быть описано в отдельном стандарте, разработанном на основе NETWM.

Рендеринг, комозитинг:

У окна имеются аттрибуты color-canvas, mask-canvas и sensitivity-canvas, содержащие идентификаторы поверхностей.
color-canvas хранит значения RGBA пикселей окна.
mask-canvas хранит маску, определяющую изменяется ли данный пиксель при наложении изображения дочерних окон.
sensitivity-canvas хранит битовый признак для каждого пикселя, определяющий чувствительность окна к событиям ввода.

Если у окна color-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все пиксели color-canvas полностью прозрачны.
Если у окна mask-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все фрагменты mask-canvas равны единице.
Если у окна sensitivity-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все фрагменты sensitivity-canvas равны единице.

Если размеры color-canvas, mask-canvas или sensitivity-canvas не совпадают с размерами окна, результат рендеринга такого окна не определен.

У окна имеется аттрибут blending-mode, указывающий, как при рендеринге следует интепретировать альфа-канал полотна color-canvas. Значения: const — альфа-канал полотна color-canvas без изменений попадает в альфа-канал результирующего полотна; layered — color-canvas обрабатывается по тому же алгоритму, что и полотна дочерних окон.

У окна имеется булев аттрибут mapped, указывающий, учитывается ли окно в рендеринге вывода и обработке ввода.
У окна имеется булев аттрибут visible, указывающий, следует ли клиенту, отвечающему за это окно, обновлять его содержимое.

Композитный менеджер выполняет в оконной подсистеме две связанные функции:

• Осуществляет рендеринг иерархии окон для получения результирующего полотна (пригодного для вывода на экран или дальнейшей обработки).
• Осуществляет диспетчерезацию событий ввода от устройств позиционирования вглубь иерархии.

У каждого окна есть аттрибут target-canvas, который указывает на полотно, содержащее результат рендеринга данного окна композитным менеджером. Любой клиент может запросить значение target-canvas, чтобы «видеть», как «выглядит» «готовое» окно. Обычно это требуется композитному менеджеру родительского окна для наложения изображения дочерних окон, но не ограничивается этим. Другие возможные применения: утилиты для снятия скриншотов, отображение превью окон в различных утилитах управления окнами и т.п.

Пусть клиент C желает выступить композитным менеджером для окна W. Для этого он подписывается на событие composite-render данного окна. Одновременно только один клиент может быть подписан на событие composite-render, таким образом у окна может быть только один композитный менеджер. Если на это событие уже был подписан другой клиент, ему отправляется сообщение composite-render, и после этого он сразу теряет подписку на это сообщение. Если ни один клиент не подписан на composite-render, рендеринг данного окна осуществляется встроенным композитным менеджером.

Композитный менеджер обязан своевременно обновлять target-canvas. Для этого он должен подписаться на все события окна W и его дочерних окон, сообщающих о изменениях состояния, после которых требуется обновить результирующий вид окна.

По аналогии с composite-render, существует событие composite-input для регистрации клиента как менеджера, отвечающего за диспетчерезацию событий от устройств позиционирования. Если на composite-input не подписан ни один клиент, диспетчерезацию выполняет встроенный композитный менеджер.

Когда серверу требуется доставить событие от устройства позиционирования, он посылает клиенту, который подписан на composite-input, сообщение composite-input-pointer-state. Клиент обязан определить путь «прохождения» сообщения по его дочерним окнам и ответить одним из следующих запросов:

• composite-input-pointer-state-dispath-list. Если сообщение «попадает» в дочерние окна, клиент отсылает запрос composite-input-pointer-state-dispath-list, который содержит исходное событие и упорядоченный по «высоте» список дочерних окон, которые «задевает» данное сообщение, а также координаты точки «задевания» для каждого дочернего окна. Сервер попробует диспетчеризировать сообщение каждому из указанных окон. Если все они вернут composite-input-pointer-state-dispath-down, событие pointer-state будет отослано «данному» окну.
• (снова) composite-input-pointer-state-dispath-list. Если сообщение не «задевает» ни одного дочернего окна, но задевает «данное» окно, клиент отсылает запрос composite-input-pointer-state-dispath-list с пустым списком окон. После этого сервер отошлет «данному» окну событие pointer-state.
• composite-input-pointer-state-dispath-down. Если событие прошло «насквозь», не задев ни дочерние окна, ни поверхность «данного» окна, клиент отсылает запрос composite-input-pointer-state-dispath-down для диспетчеризации события дальше «вниз» по z-координате.

Продолжу. Итак, оконная подсистема и композитор.

Абстракция окна служит нескольким целям: interclient communication (ICC), логическая организация пользовательского интерфейса, физическая организация пользовательского интерфейса. Подробнее:

• С точки зрения взаимодействия производных клиентов: клиентам нужен механизм ICC. Поэтому окно является основным объектом для работы ICC. Клиенты могут отправлять окнам сообщения, устанавливать и получать значения произвольных свойств, подписываться на получение сообщений от окон и т.п. Тот механизм ICC, который имеется в X11, сделан в достаточной мере хорошо. Его имеет смысл взять за основу. (Возможно, с некоторым расширением фич.)
• С точки зрения оконного менеджера: WM служит для логического («смыслового») управления элементами пользовательского интерфейса. Поэтому требуется возможность организовывать окна иерархически.
• С точки зрения композитного менеджера: CM служит для диспетчеризации ввода между клиентами и для «сборки» итогового изображения, т.е. для «физического» управления элементами интерфейса. Для CM можно использовать либо ту же иерархию, что и для WM, либо реализовывать собственную («вручную», да).
• С точки зрения возможности встраивания одного агента в графический интерфейс другого агента. Одно приложение может захотеть управлять интерфейсом другого приложения — логически и/или физически — т.е. выполнять функции WM или CM. Поэтому понятия WM и CM следует рассматривать не как специальные приложения или часть сервера (привет вейланду), а как роли, которые может на себя взять любой клиент по отношению к любому другому клиенту. Сервер должен быть так спроектирован, чтобы этому просто не мешать. (Снова привет вейланду.)

Про ICC я писать не буду, в первом приближении можно считать, что оно принципиально не отличается от используемого в X11.

Иерархия окон:

Каждый экран имеет корневое окно (root window).
Каждое окно может иметь произвольное число дочерних окон. Каждое окно имеет ровно одного родителя (кроме корневого окна, не имеющего родителя).
При уничтожении окна уничтожаются все дочерние окна. (TODO: возможно, требует доработки в рамках работы над сессионностью.)
Иерархию можно произвольно модифицировать, т.е. переносить окно от одного родителя к другому.
Каждое окно имеет координаты (относительно родительского окна) и размер.
Каждое окно имеет z-координату для упорядочивания всех окон с общим родителем в стек.

Таким образом, логическая иерархия окон также не отличается принципиально от используемой в X11.

Прикладной «смысл» оконной иерархии лежит за пределами спецификации Xnext. (Даём механизм, а не политику.) Управление верхнеуровневыми окнами приложений должно быть описано в отдельном стандарте, разработанном на основе NETWM.

Рендеринг, комозитинг:

У окна имеются аттрибуты color-canvas, mask-canvas и sensitivity-canvas, содержащие идентификаторы поверхностей.
color-canvas хранит значения RGBA пикселей окна.
mask-canvas хранит маску, определяющую изменяется ли данный пиксель при наложении изображения дочерних окон.
sensitivity-canvas хранит битовый признак для каждого пикселя, определяющий чувствительность окна к событиям ввода.

Если у окна color-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все пиксели color-canvas полностью прозрачны.
Если у окна mask-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все фрагменты mask-canvas равны единице.
Если у окна sensitivity-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все фрагменты sensitivity-canvas равны единице.

Если размеры color-canvas, mask-canvas или sensitivity-canvas не совпадают с размерами окна, результат рендеринга такого окна не определен.

У окна имеется аттрибут blending-mode, указывающий, как при рендеринге следует интепретировать альфа-канал полотна color-canvas. Зачения: const — альфа-канал полотна color-canvas без изменений попадает в альфа-канал результирующего полотна; layered — color-canvas обрабатывается по тому же алгоритму, что и полотна дочерних окон.

У окна имеется булев аттрибут mapped, указывающий, учитывается ли окно в рендеринге вывода и обработке ввода.
У окна имеется булев аттрибут visible, указывающий, следует ли клиенту, отвечающему за это окно, обновлять его содержимое.

Композитный менеджер выполняет в оконной подсистеме две связанные функции:

• Осуществляет рендеринг иерархии окон для получения результирующего полотна (пригодного для вывода на экран или дальнейшей обработки).
• Осуществляет диспетчерезацию событий ввода от устройств позиционирования вглубь иерархии.

У каждого окна есть аттрибут target-canvas, который указывает на полотно, содержащее результат рендеринга данного окна композитным менеджером. Любой клиент может запросить значение target-canvas, чтобы «видеть», как «выглядит» «готовое» окно. Обычно это требуется композитному менеджеру родительского окна для наложения изображения дочерних окон, но не ограничивается этим. Другие возможные применения: утилиты для снятия скриншотов, отображение превью окон в различных утилитах управления окнами и т.п.

Пусть клиент C желает выступить композитным менеджером для окна W. Для этого он подписывается на событие composite-render данного окна. Одновременно только один клиент может быть подписан на событие composite-render, таким образом у окна может быть только один композитный менеджер. Если на это событие уже был подписан другой клиент, ему отправляется сообщение composite-render, и после этого он сразу теряет подписку на это сообщение. Если ни один клиент не подписан на composite-render, рендеринг данного окна осуществляется встроенным композитным менеджером.

Композитный менеджер обязан своевременно обновлять target-canvas. Для этого он должен подписаться на все события окна W и его дочерних окон, сообщающих о изменениях состояния, после которых требуется обновить результирующий вид окна.

По аналогии с composite-render, существует событие composite-input для регистрации клиента как менеджера, отвечающего за диспетчерезацию событий от устройств позиционирования. Если на composite-input не подписан ни один клиент, диспетчерезацию выполняет встроенный композитный менеджер.

Когда серверу требуется доставить событие от устройства позиционирования, он посылает клиенту, который подписан на composite-input, сообщение composite-input-pointer-state. Клиент обязан определить путь «прохождения» сообщения по его дочерним окнам и ответить одним из следующих запросов:

• composite-input-pointer-state-dispath-list. Если сообщение «попадает» в дочерние окна, клиент отсылает запрос composite-input-pointer-state-dispath-list, который содержит исходное событие и упорядоченный по «высоте» список дочерних окон, которые «задевает» данное сообщение, а также координаты точки «задевания» для каждого дочернего окна. Сервер попробует диспетчеризировать сообщение каждому из указанных окон. Если все они вернут composite-input-pointer-state-dispath-down, событие pointer-state будет отослано «данному» окну.
• (снова) composite-input-pointer-state-dispath-list. Если сообщение не «задевает» ни одного дочернего окна, но задевает «данное» окно, клиент отсылает запрос composite-input-pointer-state-dispath-list с пустым списком окон. После этого сервер отошлет «данному» окну событие pointer-state.
• composite-input-pointer-state-dispath-down. Если событие прошло «насквозь», не задев ни дочерние окна, ни поверхность «данного» окна, клиент отсылает запрос composite-input-pointer-state-dispath-down для диспетчеризации события дальше «вниз» по z-координате.

Продолжу. Итак, оконная подсистема и композитор.

Абстракция окна служит нескольким целям: interclient communication (ICC), логическая организация пользовательского интерфейса, физическая организация пользовательского интерфейса. Подробнее:

• С точки зрения взаимодействия производных клиентов: клиентам нужен механизм ICC. Поэтому окно является основным объектом для работы ICC. Клиенты могут отправлять окнам сообщения, устанавливать и получать значения произвольных свойств, подписываться на получение сообщений от окон и т.п. Тот механизм ICC, который имеется в X11, сделан в достаточной мере хорошо. Его имеет смысл взять за основу. (Возможно, с некоторым расширением фич.)
• С точки зрения оконного менеджера: WM служит для логического («смыслового») управления элементами пользовательского интерфейса. Поэтому требуется возможность организовывать окна иерархически.
• С точки зрения композитного менеджера: CM служит для диспетчеризации ввода между клиентами и для «сборки» итогового изображения, т.е. для «физического» управления элементами интерфейса. Для CM можно использовать либо ту же иерархию, что и для WM, либо реализовывать собственную («вручную», да).
• С точки зрения возможности встраивания одного агента в графический интерфейс другого агента. Одно приложение может захотеть управлять интерфейсом другого приложения — логически и/или физически — т.е. выполнять функции WM или CM. Поэтому понятия WM и CM следует рассматривать не как специальные приложения или часть сервера (привет вейланду), а как роли, которые может на себя взять любой клиент по отношению к любому другому клиенту. Сервер должен быть так спроектирован, чтобы этому просто не мешать. (Снова привет вейланду.)

Про ICC я писать не буду, в первом приближении можно считать, что оно принципиально не отличается от используемого в X11.

Иерархия окон:

Каждый экран имеет корневое окно (root window).
Каждое окно может иметь произвольное число дочерних окон. Каждое окно имеет ровно одного родителя (кроме корневого окна, не имеющего родителя).
При уничтожении окна уничтожаются все дочерние окна. (TODO: возможно, требует доработки в рамках работы над сессионностью.)
Иерархию можно произвольно модифицировать, т.е. переносить окно от одного родителя к другому.
Каждое окно имеет кординаты (относительно родительского окна) и размер.
Каждое окно имеет z-координату для упорядочивания всех окон с общим родителем в стек.

Таким образом, логическая иерархия окон также не отличается принципиально от используемой в X11.

Прикладной «смысл» оконной иерархии лежит за пределами спецификации Xnext. (Даём механизм, а не политику.) Управление верхнеуровневыми окнами приложений должно быть описано в отдельном стандарте, разработанном на основе NETWM.

Рендеринг, комозитинг:

У окна имеются аттрибуты color-canvas, mask-canvas и sensitivity-canvas, содержащие идентификаторы поверхностей.
color-canvas хранит значения RGBA пикселей окна.
mask-canvas хранит маску, определяющую изменяется ли данный пиксель при наложении изображения дочерних окон.
sensitivity-canvas хранит битовый признак для каждого пикселя, определяющий чувствительность окна к событиям ввода.

Если у окна color-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все пиксели color-canvas полностью прозрачны.
Если у окна mask-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все фрагменты mask-canvas равны единице.
Если у окна sensitivity-canvas не установлен (равен None), композитный менеджер должен обрабатывать это так, будто все фрагменты sensitivity-canvas равны единице.

Если размеры color-canvas, mask-canvas или sensitivity-canvas не совпадают с размерами окна, результат рендеринга такого окна не определен.

У окна имеется аттрибут blending-mode, указывающий, как при рендеринге следует интепретировать альфа-канал полотна color-canvas. Зачения: const — альфа-канал полотна color-canvas без изменений попадает в альфа-канал результирующего полотна; layered — color-canvas обрабатывается по тому же алгоритму, что и полотна дочерних окон.

У окна имеется булев аттрибут mapped, указывающий, учитывается ли окно в рендеринге вывода и обработке ввода.
У окна имеется булев аттрибут visible, указывающий, следует ли клиенту, отвечающему за это окно, обновлять его содержимое.

Композитный менеджер выполняет в оконной подсистеме две связанные функции:

• Осуществляет рендеринг иерархии окон для получения результирующего полотна (пригодного для вывода на экран или дальнейшей обработки).
• Осуществляет диспетчерезацию событий ввода от устройств позиционирования вглубь иерархии.

У каждого окна есть аттрибут target-canvas, который указывает на полотно, содержащее результат рендеринга данного окна композитным менеджером. Любой клиент может запросить значение target-canvas, чтобы «видеть», как «выглядит» «готовое» окно. Обычно это требуется композитному менеджеру родительского окна для наложения изображения дочерних окон, но не ограничивается этим. Другие возможные применения: утилиты для снятия скриншотов, отображение превью окон в различных утилитах управления окнами и т.п.

Пусть клиент C желает выступить композитным менеджером для окна W. Для этого он подписывается на событие composite-render данного окна. Одновременно только один клиент может быть подписан на событие composite-render, таким образом у окна может быть только один композитный менеджер. Если на это событие уже был подписан другой клиент, ему отправляется сообщение composite-render, и после этого он сразу теряет подписку на это сообщение. Если ни один клиент не подписан на composite-render, рендеринг данного окна осуществляется встроенным композитным менеджером.

Композитный менеджер обязан своевременно обновлять target-canvas. Для этого он должен подписаться на все события окна W и его дочерних окон, сообщающих о изменениях состояния, после которых требуется обновить результирующий вид окна.

По аналогии с composite-render, существует событие composite-input для регистрации клиента как менеджера, отвечающего за диспетчерезацию событий от устройств позиционирования. Если на composite-input не подписан ни один клиент, диспетчерезацию выполняет встроенный композитный менеджер.

Когда серверу требуется доставить событие от устройства позиционирования, он посылает клиенту, который подписан на composite-input, сообщение composite-input-pointer-state. Клиент обязан определить путь «прохождения» сообщения по его дочерним окнам и ответить одним из следующих запросов:

• composite-input-pointer-state-dispath-list. Если сообщение «попадает» в дочерние окна, клиент отсылает запрос composite-input-pointer-state-dispath-list, который содержит исходное событие и упорядоченный по «высоте» список дочерних окон, которые «задевает» данное сообщение, а также координаты точки «задевания» для каждого дочернего окна. Сервер попробует диспетчеризировать сообщение каждому из указанных окон. Если все они вернут composite-input-pointer-state-dispath-down, событие pointer-state будет отослано «данному» окну.
• (снова) composite-input-pointer-state-dispath-list. Если сообщение не «задевает» ни одного дочернего окна, но задевает «данное» окно, клиент отсылает запрос composite-input-pointer-state-dispath-list с пустым списком окон. После этого сервер отошлет «данному» окну событие pointer-state.
• composite-input-pointer-state-dispath-down. Если событие прошло «насквозь», не задев ни дочерние окна, ни поверхность «данного» окна, клиент отсылает запрос composite-input-pointer-state-dispath-down для диспетчеризации события дальше «вниз» по z-координате.