Хоть бы в General или еще куда, не порть святой Development. И вообще тупняк - в толксы, я только туда тупняк пишу. И анонимуы не нужны, обойдемся

Поддерживаю. Продолжать обсуждение — не мешки ворочать.

Так что прочь из Development.

не порть святой Development.

Одна из немногих тем обсуждения, укладывающихся в Development.

И анонимуы не нужны

Среди них очень большой разброс, и попадаются выдающие очень толковые мысли.

Не в теме — не встревай. В отличие от бесконечных «иос нарисовала новые иконки» и потоков танцпола, мы там серьёзные вещи обсуждали.

И вообще тупняк - в толксы, я только туда тупняк пишу

Вот и не пиши в devel тупняк.

// а где можна склонировать geekless’а?

это все конечно хорошо, но пожалуйста не разрывайся на разные проэкты. начать миллион важных заданий и незакончить ни одно тоже не есть хорошо..

// ^мое имхо

и да, я бы перенес те сообщения сюда. или в ОП, или как обычное

это все конечно хорошо, но пожалуйста не разрывайся на разные проэкты. начать миллион важных заданий и незакончить ни одно тоже не есть хорошо..

Если тот анонимус, что собирался организовать команду, еще не передумал и объявится тут, то я конечно займусь этим проектом. Потому что заниматься оплачиваемым И интересным всё-таки намного лучше, чем оплачиваемым ЛИБО интересным.

тот анонимус

я бросил читать тот тред после 5й страницы. дай линк пожалуйста

и да, я бы перенес те сообщения сюда. или в ОП, или как обычное

Точно, надо перенести.

> .. на 1000-м постинге до меня начинает доходить что копаем глубоко, но похоже не в ту сторону... =) Нам бы по-хорошему дотянуть Х11 до Х12, а мы тут уже супер-спецификации супер-протоколов готовы родить... =) IMHO, несколько не то... =)

На самом деле Х12 в том виде, как он в общих чертах описан, бесполезен и не нужен. Что нужно:

• Разумеется, исправить все Encoding bugs, как это описано в http://www.x.org/wiki/Development/X12 , но этого не достаточно. Core Protocol надо выкинуть почти весь. От Core Protocol нужны только средства interclient communication.
• Продумать API, которое будет служить драйверо-независимым клеем между следующими сущностями: различными рисующими API (собственно, OGL и XRender) со стороны клиента и GPU со стороны сервера. Такое API абстрагирует нас от деталей реализации как дисплея, так и клиента, даёт возможность при помощи расширений протокола объявлять новые рисующие API в будущем, автоматически предоставляет сетевую прозрачность на уровне команд отрисовки и (теоретически, при поддержке на клиенте) даёт возможность динамической реконфигурации сервера, вплоть до смены GPU и драйверов «на лету».
• Новая подсистема обработки ввода и API для неё. Насколько я понимаю, XInput 2 хорошо подходит. Но вот что там с раскладками, не уверен, т.к. не знаком в деталях с подсистемой ввода иксов. Тут хорошо бы кого-то, кто в теме.
• Подсистема для абстракции «окно». Т.е. API для работы с деревом окон, встроенный композитор, возможность подменять встроенный композитор внешним.

Над пунктами 1, 2 и 4 я помаленьку думаю в свободное время. Постеперенно вырисовывается, как всё организовать.

В принципе, я не считаю задачу неподъемной. Если есть финансы и отчётливое желание реализовать систему с хорошими API с запасом на будущее, то проект вполне реален.

Я пытаюсь продумать механизм взаимодействия клиента с дисплеем таким образом, чтобы:

• Рендеринг осуществлялся с максимальной производительностью при выводе на локальной машине.
• Клиенту не нужно было заботиться о том, локальный дисплей или нет: если дисплей удаленный, команды рендеринга просто прозрачно для клиента форвардятся на удаленную машину.
• Клиент мог пережить динамическое переконфигурирование дисплея: подключение и отключение мониторов, gpu, перезапуск драйверов и т.п., т.е. ситуации потери контекста рендеринга.

Для этого нам нужен промежуточный API, абстрагированный как от кишок реализации дисплея, так и от конкретного рисующего API. В рамках изложения условно назовём этот промежуточный API — XNext. Вот мои соображения:

В качестве примеров рисующего API я рассматриваю следующие: OpenGL и некий аналог XRender (обернутый в cairo). Можно умозрительно заменить XRender на Direct2D, например. В общем, это какое-то API, которое более понятно для типичного прикладного программиста, чем навороченный OGL.

Клиент обменивается не критичными к производительности данными с дисплейным сервером через сокет. XNext предоставляет следующие сущности клиенту:

Экраны (Screens). Это абстрактные сущности, служащие местом отображения данных. Каждый экран содержит один или несколкьо вьюпортов.

Вьюпорты (Viewports). Это области на экране, которые сопоставлены устройствам отображения графики, т.е. мониторам. Если у нас мультимониторная конфигурация с общим рабоим столом, у нас как раз будет несколько вьюпортов на одном экране.

Устройства (Devices). Это, собственно, GPU. С каждым экраном связано устройство. API позволяет приложению узнать: «если хочешь выводить графику на вот этот экран, используй вот такое устройство». Кроме того, могут быть устройства, не связанные с какими-либо экранами (предназначены только для вычислений, без показа результата на экране).

Вся эта конфигурация может меняться динамически. Вьюпорты могут менять расположение, появляться и исчезать. Устройство вместе с экраном может полностью «отвалиться», т.е. быть выключенным «на горячую» или просто пропасть в результате программного сбоя. Клиенту нужно быть к этому готовым.

Полотна (Canvases). Полотно — это хэндл для рендеринга графики на устройстве. Полотно привязано к устройству. Если устройство исчезает, полотно становится невалидным. Полотно имеет размеры (ширина и высота в пикселях) и, вероятно, еще какие-то аттрибуты. (Не уверен, относится ли формат хранения пикселей к полотну или к контексту рисования в нём.)

Полотно служит для следующего:

• На полотне можно инициализировать контекст рисующего API и писать туда графику. На полотне также можно инициализировать контекст рисующего API и читать оттуда графику. При этом ввод и вывод полностью развязаны: например, один клиент может рисовать в полотно при помощи OpenGL, а другой использовать эти данные при помощи XRender. Таким образом, полотно служит абстракцией от способа рисования. Через 10 лет у нас для риcования могут использоваться совершенно новые API, но точкой их стыковки друг с другом будет служить всё так же полотно.
• Клиент может послать полотну уведомление о изменении содержимого, и оно придёт всем клиентам, кто подписан на данное уведомление. (Аналог расширения DAMAGE в X11.) Основное предназначение этой фичи — возможность посылать в композитор уведомления о том, что следует обновить отображение.

Для инициализации рисующего API используется механизм, схожий с DRI2. То есть: клиент запрашивает у сервера имя библиотеки для рисования, загружает эту библиотеку, авторизуется у ядреного драйвера через обмен cookie и затем получает у сервера контекст рисования для полотна. После этого библиотека, в которой реализовано рисующее API, взаимодействует непосредственно с ядром, без необходимости обмениваться данными по сокету.

Если сервер находится на удаленной машине, он возвращает пустую строку вместо имени библиотеки. После этого клиент делает следующее: подгружает (стандартную, девайсо-независимую) библиотеку, которая предоставляет тот же самый API. Данная библиоткека прозрачно для клиента перенаправляет команды рисования через сокет на сервер. На сервере осуществляется вызор реальных функций рисования.

Итак, что получается. Для того, чтобы что-нибудь нарисовать, клиент после запуска делает делает следующее:

• Получает ID устройства.
• Запрашивает для данного устройства имя библиотеки, реализующей API рисования.
• Загружает эту библиотеку в своё адресное пространство. Если сервер вернул пустое имя библиотеки, то загружает некоторую «стандартную» библиотеку.
• Создаёт на устройстве полотно.
• В рисующей библиотеке вызывает функцию для создания контекста на этом полотне.
• Рисует в созданном контексте при помощи стандартного рисующего API.

Клиенту следует быть готовым, что контекст и полотно в любой момент могут стать невалидными. В этом случае он может заново получить ID устройства и переинициализировать библиотеку, полотно и контекст. (Сервер может иметь любые скрытые механизмы управления выводом графики. Например, отключить клиента от локального GPU и подключить удаленное GPU. Если клиент готов к динамической переконфигурации графического стека, он это переживёт.)

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

Абстракция окна служит нескольким целям: 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-координате.

Как работает встроенный композитный менеджер:

Рендеринг target-canvas встроенный CM осуществляет следующим образом. Псевдокод:

/* копируем в target-canvas содержимое color-canvas */
copy(target-canvas, color-canvas);

/* цикл по всем дочерним mapped окнам в z-порядке снизу вверх */
foreach (reverse(zorder(filter(children, mapped))) => child) {
   /* наложить на target-canvas изображение дочернего окна */
   composite(
       target-canvas,
       mask-canvas, /* накладываем с учетом маски */
       child.target-canvas,
       child.x, child.y, /* по соответствующим координатам */
       child.width, child.heght,
       blend-mode /* с учётом режима изменения альфа-канала */
   );
}

Диспетчерезация ввода встроенным CM осуществляется следующим образом. Псевдокод:

/* если соответствующий фрагмент в sensitivity-canvas равен 0, событие проваливается "вниз" */
if (hittest(sensitivity-canvas, x, y) == false) {
   send(composite-input-pointer-state-dispath-down);
   return;
}

/* цикл по всем дочерним mapped окнам в z-порядке сверху вниз */
hit-children = list();
foreach (zorder(filter(children, mapped)) => child) {
    /* если событие проходит через окно, добавляем окно в список hit-children */
    if (child.x <= x &&
        child.y <= y &&
        x < child.x + child.width &&
        y < child.y + child.height
    ) {
        push(hit-children, tuple(child, x - child.x, y - child.y));
    }
}

/* посылаем composite-input-pointer-state-dispath-to-children */
send(composite-input-pointer-state-dispath-list, hit-children);

В случае, когда внешние CM не вмешиваются в логику работы сервера, алгоритмы рендеринга и диспетчеризации встроенного CM могут быть реализованы с очень хорошим уровнем эффективности. В случае, когда используются внешние CM (или просто приложения, которые запрашивают target-canvas), эффетивность внутреннего композитора менеджера «на стыке» с ними может быть ниже. В любом случае, наблюдаемая логика работы всегда соответствует описанным выше правилам и алгоритмам.

сам себе отвечу

Ситуация с Wayland: факты о X и Wayland. (комментарий)

если это «начнет» взлетать — это будет первый F(L)OSS проект которому я задонейчу. CM для Moto Defy не в счет

я бросил читать тот тред после 5й страницы. дай линк пожалуйста

Ситуация с Wayland: факты о X и Wayland. (комментарий)

и еще: мож попросить модеров закрепить тред?

Блин, опечаток-то сколько.

s/dispath/dispatch/

спасибо от анона за перенос топика сюда! :)
в толксы не надо, нас туда не пускают — здесь самое место

теперь по существу:
1) «Клиент мог пережить динамическое переконфигурирование дисплея: подключение и отключение мониторов, gpu, перезапуск драйверов и т.п., т.е. ситуации потери контекста рендеринга.»
я правильно понимаю, что выполнение этого требования также позволит вновь подключаться к удаленному приложению после обрыва связи с ним из-за проблем в сети? В этом случае, здесь сразу напрашивается подход, который кто-то уже описал в родительском треде: X-клиент запускается, и ждет соединения от X-сервера, а когда одно соединение отвалится, то к этому клиенту может подключиться, вообще говоря, другой X-сервер с другого хоста и с другим дисплеем, GPU, вводом — короче, другой терминал; не представляю, как это реализовать, но было бы здорово;

2) вообще, хорошо бы продумать такую архитектуру, которую можно было бы использовать потом для построения некоторого «домена приложений», в котором есть а) хосты для запуска приложений, б) устройства вывода (мониторы, телевизоры, дисплеи смартфонов...), в) устройства ввода (клавы, мыши, тачпады...); например, все ресурсы квартиры регистрируются в таком домене, а потом можно удобно и легко переключать на лету устройства вывода и ввода у любого однажды запущенного на каком-то хосте приложения — типа, смотрит компания друзей LIVE-трансляцию футбола через sopcast (vlc на десктопе) на большом телевизоре (подключен к десктопу по hdmi) в гостинной, и вдруг одному нужно отлучиться ненадолго, тогда он просит vlc-окно создать еще один x-клиент с копией первичного, подключается к нему со своего x-сервера на смарте (по wifi), и может тоже кричать «ГОЛ!» прямо из толчка :)

3) ты пишешь, что «XNext предоставляет следующие сущности клиенту: Экраны (Screens), Вьюпорты (Viewports), Устройства (Devices), Полотна (Canvases)».
Наверно, в целях абстракции клиент то как раз и не должен ничего знать про Viewports и Devices — это уже сущности для работы x-сервера; возможно и про Canvases то же самое, но не очень врубился в них (я несколько далек от деталей реализации графической системы, просто хочу поучаствовать в проектировании грамотной системы хотя бы на уровне требований и общей архитектуры)

«Для этого нам нужен промежуточный API, абстрагированный как от кишок реализации дисплея, так и от конкретного рисующего API»

вот поэтому я и пытался сделать свой DRI.

уровень 0: дрова видяхи. предельно тупые и не имеющие торчащего в userspace API.

уровень 1: в ядре модуль DRI, позволяющий получить все GPUхи, их типы, типы доступных ресурсов, реализующий базовые функции управления ресурсами: allocate, free, execute, send+getback(для прокидывания текстурок к WM и забору освободившихся буферов). ресурсы типа «память», «процессор(gpu, video, etc)», mapping(есть хитрая идея на сей счет), еще что нибудь(тип по FOURCC). Напр. для радеонов будет «VRAM»-просто видеопамять, «URAM»-память UVD, «GPU.», «UVD2» или «UVD3» - он вполне себе ресурс. все это можно выделять. например для opencl нужно уметь делить GPU.

сам драйвер(уровень 0) умеет только выполнять запросы - т.е. запустить шейдер/кернел/кодек, выделить/освободить память, копировать, управлять MMU. Он думать не должен, т.к. я насмотрелся, что проприетащики городят.

Уровень 2: libdrm+api для доступа к этим самым базовым функциям в ядре. На уровне 2 можно сделать затычку для проброса GPU по сети, но некоторые особо умные бро любят ниже лочить поверхности.

Уровень 3: userspace драйвер для компиляции шейдеров/кернелов и декодирования видео. Шейдеры и видео достаточно стандартны так что здесь можно обойтись довольно общим API. Здесь тоже можно сделать затычку для проброса по сети.

Уровень 4: vaapi, vdpau, opengl-переходник и opencl-переходник для уровня 3. Здесь тоже можно наделать backendов

Xlib будет в норме просто работать с X насчет ввода, а в случае работы по сети-втыкаться еще и на уровень 3 и тырить-тырить-тырить.

я правильно понимаю, что выполнение этого требования также позволит вновь подключаться к удаленному приложению после обрыва связи с ним из-за проблем в сети? В этом случае, здесь сразу напрашивается подход, который кто-то уже описал в родительском треде: X-клиент запускается, и ждет соединения от X-сервера, а когда одно соединение отвалится, то к этому клиенту может подключиться, вообще говоря, другой X-сервер с другого хоста и с другим дисплеем, GPU, вводом — короче, другой терминал; не представляю, как это реализовать, но было бы здорово;

Да, я тоже в этом направлении думаю. Есть несколько аспектов у этой ситуации:

• Физическое подключение. Правила установки соединения надо описывать в отдельной спеке, оставим их пока за рамками XNext. Но в общих чертах нет никаких препятствий, чтобы были самые разные варианты: 1) клиент может подсоединиться к серверу по указанному адресу; 2) сервер может подсоединиться к клиенту по указанному адресу; 3) клиент может быть подключен к локальному прокси-серверу, который сам ничего не делает, но ждёт пока к нему подключится «настоящий» сервер. (Сервером его уже правда некорректно в этом случае называть, лучше говорить «дисплей», а вместо клиента — «приложение».) В общем, вариантов можно придумать много. Тут есть такой момент: если соединение отвалилось, как программе узнать, что делать: самоубиться, или ждать входящего подключения, или попробовать подключиться к какому-то адресу? Я считаю так: если уж dbus стал использоваться как стандарт для коммуникации в пределах локалхоста, то его можно использовать как шину управления приложением. Допустим, ситуация: Вот сдох у нас дисплейный сервер, мы запустили другой комп с другим IP адресом. А приложения, которые на другом конце глобуса, ломятся на старый адрес. Тогда мы заходим через ssh на ту машину, где запущены приложения и через специальную команду, посылающую сообщения dbus, говорим им, чтобы они к другому адресу подсоединялись.
• Графический контекст. Это то, о чем я в постах ранее писал. Клиент должен быть написан с учетом того, что устройство рисования в любой момент отвалится и, например, через 5 секунд появится другое. Клиенту придётся переинициализировать графический стек, перезагрузить все текстуры и т.п.
• Окна. Тут два варианта: либо при пропадании коннекта исчезает Screen, и все окна также удаляются (т.к. они привязаны к screen-у). И приложению при переподключении иерархию окон нужно будет создавать заново. Либо при пропадании коннекта клиент видит, что вокруг него «весь мир исчез» (исчезли все другие клиенты и окна), а он один остался на экране со своими окнами. А при возобновлении коннекта опять начинает видеть других «участников». Какой вариант выбрать, я пока не знаю. От этого выбора сильно зависит архитектура Xnext в целом.
• Ну и разумеется: тулкиты. Тулкиты нужно будет дорабатывать, чтобы они умели все эти ситуации правильно обработать: переинициализировать графический стек, востановить свои окна и т.п. К счастью, тулкитов распространённых всего два, а не десять.

2) вообще, хорошо бы продумать такую архитектуру, которую можно было бы использовать потом для построения некоторого «домена приложений», в котором есть а) хосты для запуска приложений, б) устройства вывода (мониторы, телевизоры, дисплеи смартфонов...), в) устройства ввода (клавы, мыши, тачпады...); например, все ресурсы квартиры регистрируются в таком домене, а потом можно удобно и легко переключать на лету устройства вывода и ввода у любого однажды запущенного на каком-то хосте приложения — типа, смотрит компания друзей LIVE-трансляцию футбола через sopcast (vlc на десктопе) на большом телевизоре (подключен к десктопу по hdmi) в гостинной, и вдруг одному нужно отлучиться ненадолго, тогда он просит vlc-окно создать еще один x-клиент с копией первичного, подключается к нему со своего x-сервера на смарте (по wifi), и может тоже кричать «ГОЛ!» прямо из толчка :)

Да, такое тоже можно в отдалённом будущем. Когда все сложности, что указаны в предыдущем абзаце, будут решены, запилить подобное не составит принципиальнйо сложности.

Наверно, в целях абстракции клиент то как раз и не должен ничего знать про Viewports и Devices — это уже сущности для работы x-сервера; возможно и про Canvases то же самое, но не очень врубился в них (я несколько далек от деталей реализации графической системы, просто хочу поучаствовать в проектировании грамотной системы хотя бы на уровне требований и общей архитектуры)

Device — это «то, что умеет рисовать». У каждого экрана есть «штука, которая умеет рисовать». Эта штука умеет рисовать не просто так, а ограниченным набором API. Например, на ноутбуке это будут OpenGL 4, Xrender и Xvideo. А на смартфоне — какой-нибудь урезанный OpenGL ES 2.0. Т.е. это абстракция для работы с драйвером видеоускорителя.

Приложение (обычно не само приложение, а тулкит) спрашивает у устройства, какие API оно умеет. Потом инициализирует какой-то из этих API (например, Qt можно настроить использовать Xrender, а можно настроить использовать OpenGL). Создаёт полотно и рисует туда. А потом на основе этого полотна композитный менеджер отображает интерфейс этого приложения на экране.

Или вот еще пример. Пусть наш какой-то-новый-кривой-тулкит умеет только через OpenGL 4 рисовать, а с OpenGL ES 2 никак не дружит. А мы хотим на смартфоне окно приложения отобразить. Что делать? Напрямую никак не получится. Тогда на локальной машине создаём виртуальный экран, в который приложение себя рендерит. И отображаем содержимое этого экрана на смартфоне через VNC.

Насчёт Viewports — это абстракция над мониторами. Разумеется, всем подряд клиентам она не нужна. Но она нужна утилитам управления окнами. Оконному менеджеру надо знать, сколько мониторов подключено и как они логически расположены. Например, чтобы окно распахивалось только на один монитор а не на все. (Или наоборот: на все, а не на один — как пользователь захочет.)

Ага, со стороны реализации XNext такая получается картина:

Дисплейный сервер должен работать с видеодрайвером через некоторый достаточно стабильный API (чтобы не было вот этого вот, когда вышла новая версия xorg, и у всех xf-драйверов сменилось ABI, внезапно).

Сам штатный композитор окон, который будет встроен в реализацию XNext, использует только те же API, что и приложения: OpenGL и т.п. Никаких особых «для внутреннего использования в иксах» рисующих API быть не должно.

В принципе, ему нужен только уровень 4 (или 3, смотря как границу провести), по твоей классификации. Что на на этом уровне должно быть:

• Перечисление высокоуровневыех ресурсов: какие есть gpu, какие подключены к gpu мониторы и т.п.
• Перечисление API уровня 4, которые доступны в данном окружении (vdpau, opengl...).
• Возможность создавать хэндлы для рисования, привязанные к устройству.
• Возможность к хэндлу забиндить контекст конкретного API.
• Возможность выступить посредником авторизации между ядром и приложением, чтобы сказать затем сказать приложению: «вот тебе способ динамически слинковаться с opengl-переходником, а теперь рисуй там сам».

Так-с, теперь понятен следующий этап моих изысканий: надо разобраться, насколько желаемое близко к тому, что сейчас реально есть в графическом стеке.

затычку для проброса по сети.

Имхо, самый разумный способ проброса по сети — это пробрасывать API уровня 4. Например, как OpenGL заданной версии в спецификации определена, так команды по сокету и гнать.

не порть святой Development.

Его уже испортили когда разрешили того какого то там кодера99.

вот если бы размер формочки менялся именно на дисплее, то менять его можно было бы без задержек по сети (и без гонок) хотя бы в том случае, когда клиент не подписан на сообщения изменения размера — а может быть даже и в последнем случае

Получается довольно высокоуровневенько. Например если мы изменяем ширину окошка, приложение может рисовать скролбары или переносить текст в более узком окошке. Если мы хотим обрабатывать изменения размеров на дисплее, получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно) а текст весь отправлятся дисплею, чтобы тот его сам умещал в имеющемся окне c переносами строк.

Это похоже больше на уровень тулкитов сейчас. Дисплей сервер сейчас общий и может поддерживать зоопарк разных тулкитов. Но вообще если какой-то из тулкитов мог бы поддерживать такую удаленную работу в своем API это могло бы уменьшить трафик в сетевом управление, но для дисплея это слишком высоковато имхо.

Device — это «то, что умеет рисовать». У каждого экрана есть «штука, которая умеет рисовать». Эта штука умеет рисовать не просто так, а ограниченным набором API. Например, на ноутбуке это будут OpenGL 4, Xrender и Xvideo. А на смартфоне — какой-нибудь урезанный OpenGL ES 2.0. Т.е. это абстракция для работы с драйвером видеоускорителя.

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него? какая же это тогда абстракция? Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

как-то это, вроде бы, противоречит предыдущему:

Продумать API, которое будет служить драйверо-независимым клеем между следующими сущностями: различными рисующими API (собственно, OGL и XRender) со стороны клиента и GPU со стороны сервера. Такое API абстрагирует нас от деталей реализации как дисплея, так и клиента, даёт возможность при помощи расширений протокола объявлять новые рисующие API в будущем, автоматически предоставляет сетевую прозрачность на уровне команд отрисовки и (теоретически, при поддержке на клиенте) даёт возможность динамической реконфигурации сервера, вплоть до смены GPU и драйверов «на лету».

я это понял так:
клиент:

app1 -> lib_toolkit1 ->  / API-XRender \
                         \ API-OpenGL  /  -> lib_xnext_client -> Xnext-API
app2 -> lib_toolkit2 ->    API-Xvideo     -> lib_xnext_client -> Xnext-API

сервер:

                                  / API-XRender \      /  drv_intel   -> GPU-Intel  -> monitor1
Xnext-API -> lib_xnext_server -> {  API-OpenGL   } -> {   drv_nvidia  -> GPU-Nvidia -> monitor2, monitor3
                                  \ API-Xvideo  /      \  drv_amd     -> GPU-Amd

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender
правда, я сомневался в возможности придумать такой абстрактный API

...впрочем, это уже конкретика, в которой я не разбираюсь, так что можно не обращать на меня внимания, больше не буду соваться в эту область :)

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине они никуда не «переходят». Клиент по указке сервера загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи XNext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender
правда, я сомневался в возможности придумать такой абстрактный API

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.

Наличие этих транспортов нужно будет как-то регламентировать, разумеется. А передача ими данных через сокет будет регистрироваться как расширение протокола XNext.

Тот механизм ICC, который имеется в X11, сделан в достаточной мере хорошо. Его имеет смысл взять за основу. (Возможно, с некоторым расширением фич.)

В X11 нет системного буфера обмена (т.е. буфер становится пустым после закрытия приложения, из которого было что-то скопировано), и ЕМНИП нет стандарта на то, в каком виде класть данные в буфер обмена.

Я эти сказки всё время пользования линуксом слышу, и всё это время буфер, тот самый, которого «нет», и на который стандарта «нет», всё работает и работает. Прям мистика.

В X11 нет системного буфера обмена

А еще в X11 нет оконного менеджера. Ты пользуешься X11 без оконного менеджера?

и ЕМНИП нет стандарта на то, в каком виде класть данные в буфер обмена.

Отсутствие стандарта на формат данных — это проблема механизма передачи данных, или тех дуралеев, что за 15 лет не осилили этот стандарт написать и выложить на fd.o? Ты бы еще спецификацию TCP в отсутствии стандарта на формат данных в буфере обмена упрекнул.

Я эти сказки всё время пользования линуксом слышу, и всё это время буфер, тот самый, которого «нет», и на который стандарта «нет», всё работает и работает. Прям мистика.

Буфер есть, но у приложения, а не системный. Закрывается приложение — кончается буфер.

В каких-то дистрибутивах это так, в каких-то нет. Причём сохранением буфера обмена после закрытия приложения занимается сторонняя приблуда вроде klipper в KDE. Пока она есть — буфер будет жить долго.

Имхо, самый разумный способ проброса по сети — это пробрасывать API уровня 4. Например, как OpenGL заданной версии в спецификации определена, так команды по сокету и гнать.

По этому и по всем другим пунктам, где было высказано недовольство вейландом, скажу вот что. Mir, в отличие от вейланда, фиксированного протокола не имеет. Насколько я вообще понял, Canonical во-первых хочет иметь (и уже имеет) непрерывную интеграцию и стресс-тестирование; во-вторых хочет в дальнейшем менять протокол, а совместимость целиком переложить на тулкиты. То есть при смене протокола надо будет лишь убедиться, что версия тулкита, идущая в дистрибутиве, будет иметь уже обновлённый бекенд.

Так что очень может быть, что Mir может удовлетворить вашим нужды. Сегодня в списке рассылки обсуждали, как совместить экспериментальный Mir в ubuntu 13.10 и kubuntu — люди из Canonical сказали, что на следующей неделе сделают форум для всех заинтересованных в развитии Mir (а также что нормальная работа kwin и kubuntu для них важнее, чем новый дисплейный сервер на десктопе).

А вот разработку ещё одного протокола, да без внушительной рабочей силы, в апстримных проектах не одобрит никто. Ментейнер kwin и так уже испытывает много ненависти к Mir.

кажется, я понял... :)
XNext — это действительно такой протокол управления скорее, а «рисование картинки» — это лишь один из множества функционалов, которыми он оперирует
для обеспечения рисования, он лишь помогает установить логическое соединение между клиентом и сервером, исходя из их локальности/удаленности, и наборов протоколов, которые они поддерживают
может тогда еще и звуковыми потоками пусть точно так же управляет? помогает установить логические каналы приема/передачи звука по сети, когда приложение выполняется удаленно; а когда локально — приложение просто использует либу для вывода звука на локальное звуковое устройство

Если тот анонимус, что собирался организовать команду, еще не передумал и объявится тут, то я конечно займусь этим проектом. Потому что заниматься оплачиваемым И интересным всё-таки намного лучше, чем оплачиваемым ЛИБО интересным.

Не будь наивным, никто ничего оплачивать не будет. Проекты с финансированием начинаются совершенно по-другому.

вот поэтому я и пытался сделать свой DRI.

Паккард сейчас работает над DRI3, кстати.

http://keithp.com/blogs/DRI3000/ (есть видео выступления «Future directions for the X Window System» (2013) и ссылки). В рассылке xorg это тоже обсуждается.

Буфер есть, но у приложения, а не системный. Закрывается приложение — кончается буфер. В каких-то дистрибутивах это так, в каких-то нет. Причём сохранением буфера обмена после закрытия приложения занимается сторонняя приблуда вроде klipper в KDE. Пока она есть — буфер будет жить долго.

Ты капитана изображаешь?

— А еще в X11 нет оконного менеджера. Ты пользуешься X11 без оконного менеджера?

По этому и по всем другим пунктам, где было высказано недовольство вейландом, скажу вот что. Mir, в отличие от вейланда, фиксированного протокола не имеет. Насколько я вообще понял, Canonical во-первых хочет иметь (и уже имеет) непрерывную интеграцию и стресс-тестирование; во-вторых хочет в дальнейшем менять протокол, а совместимость целиком переложить на тулкиты.

Очень конструктивно перекладывать с больной головы на здоровую. Не удивительно, что:

Ментейнер kwin и так уже испытывает много ненависти к Mir.

Что-то я этого Паккарда совсем перестал понимать. Вместо того, чтобы двигаться в сторону универсальных API, он изобретает очередной костыль под иксы.

В общем-то в чем-то разработчики вейланда правы: проще этот клубок расширений, которые дополняют расширения, которые дополняют расширения, которые дополняют расширения... разрубить одним ударом, чем дальше таскать.

Что-то я этого Паккарда совсем перестал понимать. Вместо того, чтобы двигаться в сторону универсальных API, он изобретает очередной костыль под иксы.

И совершенно правильно делает. Любое новое API - разрушение инфраструктуры и полное переписывание всего: как проекта, так и всего, что пользуется им. Гораздо более практичный путь - добавление возможностей и гибка под современные тренды в графике. Пока архитектура иксов это делать позволяет, это будут делать. Пересоздание иксов и протокола не имеет сегодня перспективы. С точки зрения программистов смысл всегда найдется - всегда кому-то что-то не нравится, всегда есть перфекционисты, но с точки зрения инфраструктурных вопросов, таких как затраченное время на стабилизацию проекта, документирование, долговременная поддержка, стабильность и обратная совместимость, сотня лет практики и т.п. - все будет полным провалом.

Никакого смысла создавать новые иксы нет, так как сетевая прозрачность имеет весьма ограниченное применение и вряд ли ее применение вдруг станет актуальнее. Глупо вкладывать долговременно огромные силы, чтобы сделать то же, что уже есть сейчас, да еще для ограниченного числа людей. Никто ничего переписывать не будет. Вся работа уйдет в мусорное ведро.

А при чем тут сетевая прозрачность вообще?

А при чем тут сетевая прозрачность вообще?

При том, что если сетевая прозрачность не планируется, то иксы технически вообще не нужны. Они будут жить только благодаря тому, что это состоявшийся и уже работающий проект. И затем, чтобы понять, ради чего весь топик заведен. Ты же хотел мнение - я его озвучиваю. Любые перепланировки и переделки иксов несовместимым образом - пустая трата времени.

1. В комментарии, на который ты отвечал, я говорил про костыли вокруг драйвера. Ты внезапно про сетевую прозрачность ответил. Это как связано вообще?

2. Ну да, сетевая прозрачность никому не нужна, реализации VNC и RDP прозябают в безызвестности и безблагодатности. Или нет?

3. Ну и касательно архитектуры. Тащить дохлый трупик иксов бесконечно не получится всё равно. Он и так уже ощутимо начинает издавать запашок и привлекать мух. Но мы лучше его положим в мавзолей и будем поклоняться, да.

При том, что если сетевая прозрачность не планируется, то иксы технически вообще не нужны.

ЯННП. На что ты отвечаешь? «сетевая прозрачность не планируется» — вот это что такое, ты уверен, что ты именно мне отвечаешь?

Иксы как кусок старого говна в исполнении xorg не нужны вне зависимости от наличия сетевой прозрачности. Иксы как идея нужны были вчера, нужны сегодня и будут нужны и через 10, и через 20 лет.

Любые перепланировки и переделки иксов несовместимым образом - пустая трата времени.

Заметь, что ты даже не спросил, рассчитываю ли я на возможность прозрачной поддержки X11 в рамках реализации XNext.

Никакого смысла создавать новые иксы нет, так как сетевая прозрачность имеет весьма ограниченное применение и вряд ли ее применение вдруг станет актуальнее. Глупо вкладывать долговременно огромные силы, чтобы сделать то же, что уже есть сейчас, да еще для ограниченного числа людей. Никто ничего переписывать не будет. Вся работа уйдет в мусорное ведро.

У нас сейчас нет:

• Вменяемого стека видеодрайверов.
• Вменяемой оконной системы.
• Вменяемой системы обработки ввода для предыдущего пункта.
• Вменяемого API для 2d-графики.
• Вменяемых тулкитов, которые бы это всё могли эффективно использовать.

Но ты видишь единственный предмет разговора в сетевой прозрачности. Это как-то... я даже, не знаю, как. Однобоко как-то.

Сетевая прозрачность как ключевая фича вообще на фоне всего этого нафиг не уперлась. Если бы всё вышеперечисленное было, сетевая прозрачность реализовывалась бы просто автоматически как следствие свойств грамотной архитектуры.

Нет ведь «никакого смысла создавать» все вышеперечисленное, гораздо проще снести линукс и накатить винду.

С точки зрения программистов смысл всегда найдется - всегда кому-то что-то не нравится, всегда есть перфекционисты, но с точки зрения инфраструктурных вопросов, таких как затраченное время на стабилизацию проекта, документирование, долговременная поддержка, стабильность и обратная совместимость, сотня лет практики и т.п. - все будет полным провалом.

Пора устанавливать Шindoшs?

А, ну понятно. Тогда разговора не получится. Я на другой платформе стою. Я за то, чтобы оставить Иксы такими, какие они есть и прогибать по мере необходимости под новые технические возможности. Развивать X эволюционно (расширения, оптимизация, чистка кода) и таким образом, чтобы все приложения, которые я использую, продолжали работать, то есть тянуть с собой весь старый крэп.

X никуда пока и не денутся. Если что-то с Иксами и случится, то будет Мир во всем Вэйленде, а никакой не XNext. Кто в нем заинтересован? На минуточку, ты себе хоть представляешь, какой объем работы был вложен в X, чтобы его повторить? Ведь X - это не только программку написать - это целая инфраструктура, поддержанная кучей производителей в свое время и поддерживаемая сейчас. Прошла куча лет, вложна масса работы, научены тысячи людей с этим работать (те, кто пишет WM, кто поддерживает WM). Людям в xorg деньги платят! Куперсмит в Oracle, Паккард - Интел (а до этого был HP), Дойчер был AMD (и сейчас, наверное), Аарон Платнер и еще кто-то - NVidia, Хюттерер - всем занимается вводом, тоже оплачиваемый товарищ, Airlie - Red Hat (по-моему). И, к слову, сейчас Core Protocol не требует такого пристального сопровождения, как может показаться.

Надеюсь, вселил неуверенности и пессимизма. Нет, я серьзено думаю, что не взлетит у тебя ничего. Интерес пропадет через годик. :)

Ну сделает он как все остальные xXNext. Вот тебе и поддержка старого щита.

Народ, ау! Куда вы все подевались?! ;) Такая тема заглохла! :(

Мегаполезный текст, не то что то, что попало в «Новости». Мне понравились такие комментарии об этом. Про "Проблемы X11 и их решения в Wayland":

Изумительный текст. Краткое содержание:
Чуваки написали свой wayland, чтобы можно было с помощью медиа-клавиш выключать звук во время работы скрин-локера, и чтобы у них при перемотке на ютубе не тормозили другие задачи.
Про сетевую прозрачность я слушать уже просто устал - они мне все доказывают, что ее нет, хотя я изо дня в день ей пользуюсь.
При всех описанных плюсах, пользоваться wayland'ом по-прежнему нельзя, потому что он как неуловимый джо.

http://www.opennet.ru/openforum/vsluhforumID3/90380.html#10

Про "Мифы про systemd":

Это опровержение по большей части декларативно.
В: системд сложный
О: системд не сложный
В: системд монолит
О: системд не монолит
В: главная задача системд скорость
О: скорость никогда не была главной задачей системд
и все в том же духе. Аргументов либо нет, либо они притянуты не к месту.

http://www.opennet.ru/openforum/vsluhforumID3/90371.html#277

Народ, ау! Куда вы все подевались?! ;) Такая тема заглохла! :(

Народу нужно что-то есть и в чем-то жить. Организаторов же не нашлось. Я лично инженер, а не менеджер.

А что такое «Вменяемого API для 2d-графики.»? Чем плох сечашний Cairo?

Народу нужно что-то есть и в чем-то жить. Организаторов же не нашлось. Я лично инженер, а не менеджер.

Так а тут же деньги россыпью сыпал один онанимус :)

Кстати, а на что они тут нужны?

Это всё очень абстрактно, в том смысле, что требует более низкоуровневого фундамента. Нам нужна основа, от которой плясать, наподобие той, что я комментом выше изложил. Ситуация с Wayland: факты о X и Wayland. (комментарий)

я понял твою мысль, но тебе надо было написать не «очень абстрактно», а ровно наоборот — «слишком конкретно»; предложенная мной архитектура местами слишком конкретна — например, не учитывает чье-то желание сделать свой вариант layout-та, когда, скажем, отталкивание от краев больше, чем отталкивание виджетов друг от друга

нужно действительно предложить более абстракный вариант — им наверно может быть "(прямоугольные?) области на дисплее с z-индексом, находящиеся как в поле зрения, так и вне его (для быстрого трансфера); команды обновляют области, двигают области, и завершаются flush; каждый юзерский эвент несет с собой sequence number-ы всех областей, кому он принадлежит"; области могут быть с альфа-масками

вот ты понаписал много что, в том числе то, в чем я кстати *нифига* не разбираюсь [хотя вот про канвасы и гпу вполне разумно... и вообще я вижу, что я часть твоих сообщений оказывается не прочел], но я не понимаю главного: предпожим, я решу делать свой велосипед (этот самый улучшенный хтмл), и тогда *зачем мне иксы*? т.е. положим, я принципиально не буду юзать тулкиты вроде gtk & qt, а буду реализовывать все на разумно низком уровне; тогда им окажется, я полагаю, libsdl — и зачем тогда *вообще* иксы? почему бы не писать драйверы под че-то типа libsdl — это же наверно проще?

т.е. да, я тут совершенно упускаю из виду взаимодействие вне одного окна, но я думаю ты сможешь мне ответить (проинформировав если надо и про этот аспект)

Например если мы изменяем ширину окошка, приложение может рисовать скролбары или переносить текст в более узком окошке. Если мы хотим обрабатывать изменения размеров на дисплее, получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно) а текст весь отправлятся дисплею, чтобы тот его сам умещал в имеющемся окне c переносами строк.

вовсе не обязательно

дисплей может разумно реагировать даже в том случае, если он до конца не знает, что за виджеты лежат там у него

вот, скажем, юзер уменьшает размер формы; тогда дисплей

1. пока возможно, стесняет виджеты ближе друг к другу

2. когда это стало невозможно, пытается переформатировать те виджеты, которые он может (ну скажем обычный текстовый виджет)

3. когда это невозможно (скажем, в текстовом виджете используется охрененая система умной расстановки переносов), то дисплей тупо пририсовывает полосы прокрутки к форме (и прокручивает ее в случае, если юзеру это надо)

кстати, охрененая система умной расстановки переносов тоже может и должна работать *поверх* тупой системы расстановки переносов (которую можно вынести на дисплей), чтобы не тормозить на файлах по 10МБ

получается что скролбары должны целиком рисоваться на дисплее (проблемы когда они должны выглядеть кастомно)

кастомно *выглядящие* скроллбары — это тупой выпендреж, а вот скроллбары с некой доп. инфой можно перерисовывать в несколько этапов — т.е. на дисплее они перерисовываются просто, а потом уже аппликуха дорисовывает полезную инфу

_*и именно так в правильно написанном приложении происходит даже локально*_, когда приложению требуется куча времени, чтобы сгенерить доп. инфу, но можно быстро сгенерить обычные скроллбары

вот близкий пример: если многомегабайтный файл загрузить в правильный браузер, а потом отресайзить окно, то в начале он тупо покажет полосы прокрутки и даст прокручивать, а потом уже через десяток-другой секунд сделает рефлоу под новую ширину экрана и переделает полосы прокрутки

Никакого смысла создавать новые иксы нет, так как сетевая прозрачность имеет весьма ограниченное применение и вряд ли ее применение вдруг станет актуальнее.

а как насчет запуска аппликух на смартфонах-планшетах через сетевую прозрачность?

Так что прочь из Development.

уж прям не знаю, как бы так вежливо сказать, что обсуждение архитектуры куда важнее, чем обуждение очередных 30 строчек кода, которые планируется добавить в многоГИГАБАЙТНУЮ свалку исходников свободного софта

именно отсутствие цельности замысла делает софт менее свободным — т.е. менее подверженным легкой модификации под свои цели

а так, вообще-то, пропатчить и бинарник можно

Народу нужно что-то есть и в чем-то жить. Организаторов же не нашлось.

а я так до сих пор не прочитал все, что требуется — хотя у меня и есть время, но чтение требует некоторого включения мозгов

Организаторов же не нашлось.

я бы не был столь категоричен

кроме того, весь этот шум и работа вокруг альтернативных реализаций (вейланда, мира, qt на андроиде) так или иначе постепенно накапливают в общем доступе полезную инфу по теме